Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!kithrup!sef From: sef@kithrup.COM (Sean Eric Fagan) Newsgroups: comp.unix.aix Subject: Re: RS6000 questions/comments Keywords: compiler problems rs6000 Message-ID: <1991Jun27.221208.14845@kithrup.COM> Date: 27 Jun 91 22:12:08 GMT References: <141@ssi.UUCP> Distribution: usa Organization: Kithrup Enterprises, Ltd. Lines: 154 In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: > * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch > command that I can find. Most machines don't. It's very simple to write an arch command, though, and I've had to install one on lots of machines. Remember, folks, all the world's not a Sun. > * Make on the rs6k doesn't seem to automatically sccs out files it can't > find, so you may need to sccs get SCCS. Are you using SysV sccs convention (s.) or BSD (SCCS/...)? If you're not using the one that the builtin rule expects, I'm not terribly surprised it doesn't do what you want, and you shouldn't be, either. > * The make on rs6k also doesn't automatically issue the .INIT rule. What is this '.INIT' rule? I've never heard of it, and I've been using makefiles for half a decade now. > * Makefiles with blank lines that have tabs in them are treated as syntax > errors by the rs6k make utility. Blank lines with tabs tend to cause problems with make, and always have. > * There is no /usr/lib/debug/malloc.o. Or at least I can't find it. Not on my machine, either. There are several debug mallocs out there; the advantage being I can get source code if I want it, and, if it doesn't provide the amount of debugging I want, I can change 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. Good for them! Doug Gwyn (among others) has a *lot* of objections to defining __STDC__ when you aren't compliant. I, personally, could argue both ways about it, and have done so before. But there is nothing wrong with what IBM did in that respect. > * 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. I wish I had a copy of the ANSI C Standard handy; I think there might be good reason they did that. But I can't remember what ANSI said about bitfields. Ah, here it is (just found a copy): "a bit-field shall have a type that is a qualified or unqualified verson of one of int, unsigned int, or signed int." An enum type can *fit* into an int, but it is not necessarily an int. At least, that is likely IBM's reasoning. I will not say whether it is good or bad. > * The rs6k compiler objected to: > #define blah(a,,b) a+b > The sun doesn't seem to care. The sun compiler is broken. > * 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. The sun compiler is broken. You said it was a float, why are you surprised to find that it is? > * 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. Any declarations in header files for any standard functions (i.e., those defined by ANSI and/or POSIX) must match the definition the standard says. Guess what: most of those don't necessarily match traditional declarations. For example, consider: extern int lstat(); /* pre-POSIX */ extern int lstat(const char *, struct stat *); /* POSIX */ If the latter is in a header file, but you use the former, that is an error. >* The rs6k C compiler gives a warning error on every use of #ident. > Another warning message to ignore. As it should. What is this "#ident"? Neither ANSI nor POSIX say anything about it. It would also, I suspect, complain about "#machine" or whatever the abortion SysVr4 uses is. >* 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. This is legitimate, although it would be nice if it did check to see if they were the same. >* 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. Both definitions are correct. See ANSI. >* The rs6k like the u370 (that's the 3090) has no vfork(). vfork() is a hack, although, I will admit, it does have its uses. The only legitimate use of vfork() is that the child will execute before the parent. However, POSIX does not (yet?) have a vfork() like function; IBM may be waiting for POSIX to decide what to do before they add one. (POSIX did have, last time I checked a draft, a proposal for a 'qfork()' which was almost-but-not-quite vfork(). So be it.) >* 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. Neither should be there in ANSI or POSIX conformance mode (assuming the compiler has such a thing). However, I will say that I believe the SysVr4 one to be *wrong* in that respect, because what if someone else wants to define a boolean type? >* The include of unistd.h includes just about everything, you may want to > avoid this file unless you really need it. Again, there are limits on what can include in POSIX conformance mode. >* 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. Not a problem, really. I don't believe that yacc output is guaranteed to be portable. You should see if you can fix the yacc template, though. -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.