Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore!uunet!ssi!cjr From: cjr@ssi.UUCP (Cris J. Rhea) Newsgroups: comp.unix.aix Subject: RS6000 questions/comments Keywords: compiler problems rs6000 Message-ID: <141@ssi.UUCP> Date: 27 Jun 91 14:51:33 GMT Distribution: usa Organization: Supercomputer Systems Inc., Eau Claire WI Lines: 97 I am one of the system admins at our company. One of our compiler folks started using one of our rs6000's and had the following comments--- seems easier to post and hope that someone in Austin will respond than try to report all of these as problems/concerns. --- Cris uunet!ssi!cjr ssi!cjr@uunet.uu.net /* ---------- "That $%%^&# RS6000" ---------- */ Here are some crude porting notes on the software I got to port and test out ok on the rs6k machines. * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch command that I can find. * Make on the rs6k doesn't seem to automatically sccs out files it can't find, so you may need to sccs get SCCS. * The make on rs6k also doesn't automatically issue the .INIT rule. * Makefiles with blank lines that have tabs in them are treated as syntax errors by the rs6k make utility. * There is no /usr/lib/debug/malloc.o. Or at least I can't find it. * On the rs6k cc does not define __STDC__ by default (unless you want strict ANSI I guess) but the #include's and cc in general appears to be an ANSI implementation. For example, it has stdlib.h, it wants sprintf() to be declared as "int sprintf();" or not at all, and it allows prototypes all the time. The SVR4 cc has the attitude that strict ANSI mode defines __STDC__ as 1 otherwise it defines it as 0, in either case it is defined. Very inconsistent and annoying. Similar problems were found with the mem*() functions and the malloc()/free()/realloc()/calloc() functions, don't declare them just use and . I almost tried a -D__STDC__=0 on the compile line, but chickened out, maybe I'll try that some other time. * Expect many warning messages about enum's, especially if used as bit field types. This is stupid, if you can't use an enum as a bit field that makes them even more worthless. * The rs6k compiler objected to: #define blah(a,,b) a+b The sun doesn't seem to care. * The rs6k compiler will demote formal parameters to the type they are specified with, the sun does not, e.g. a(f) float f; { } inside a() the f parameter (even though it is passed the entire double) will be truncated to a float before it is used. The sun cc recognizes formal parameters with type float as being more like doubles. * Don't even attempt to declare any system calls if you include any sys/*.h #include files. The chances of matching the declaration in the #include is impossible and any include of any sys/*.h #include file seems to bring in a whole nest of others, especially unistd.h. * The rs6k C compiler gives a warning error on every use of #ident. Another warning message to ignore. * The rs6k compiler complains about any macro that has been defined on the compile line and also defined in the source, even if the definitions are exactly the same. Yet another warning message to ignore. * The rs6k has defined NULL to be ((void*)0) instead of 0. This has caused numerous fatal errors in some of the SVR4 sources. Places where an unsigned or an ELF64_Addr (an unsigned) is assigned NULL. I resorted to adding a -DNULL=0 to the compile line to get around this. * The rs6k like the u370 (that's the 3090) has no vfork(). * Somewhere in the include of sys/types.h I think, there are #define's of the very popular names TRUE and FALSE. This cause problems in SVR4 ld1 e.g. it has enum{TRUE=1,FALSE=0}Boolean; in it. * The include of unistd.h includes just about everything, you may want to avoid this file unless you really need it. * The yacc source generated on the sun's will not compile on the rs6k, you will need to re-run yacc on the rs6k to get rs6k acceptable source. The sun yacc source declares things like malloc() wrong. * SCCS: If you try and SCCS a file out on the rs6k that is older than a year (I think), then sccs prints out a 4 or 5 line paragraph warning you that the file you just sccs'd out is over a year old... I guess this means that we should always be changing things, at least once a year????