relative quality of C compilers?

kaleb@mars.Jpl.Nasa.Gov (Kaleb Keithley)
25 Jan 90 18:00:38 GMT

          From comp.compilers

Related articles
relative quality of C compilers? kaleb@mars.Jpl.Nasa.Gov (1990-01-25)
| List of all articles for this month |

From: kaleb@mars.Jpl.Nasa.Gov (Kaleb Keithley)
Newsgroups: comp.compilers,comp.lang.c
Date: 25 Jan 90 18:00:38 GMT
Distribution: na
Organization: Jet Propulsion Laboratory, Pasadena, CA.

How does one tell the relative quality of a given C compiler?


For instance, lots of comments have come out of the X Window world making
claims the 680x0 u*ix compilers are poor, while the SPARC compiler is very
good. General consensus is that GNU's compiler is, on the average, better
than most.


Without going into gory details about the specific errors;
why would a given piece of code 1) Fail on the Macintosh AUX compiler?
(sysV release 2) 2) Fail on the ESIX compiler (sysV release 3) 3) compile
on the SPARC (BSD 4.2 w sysV extensions) and 4) compile on all the above
with gcc?


and, why would another given piece of code 1) compile on Macintosh clean? 2)
compile on ESIX with warnings? 3) compile on SPARC clean?


How does one anticipate these kinds of problems? We are after all, talking
about vanilla unix compilers. I could understand it if, say, we were
comparing a u*ix compiler to a DOS compliler, where some things just don't
work...


Without the benefit of years and years of experience, how does one evaluate
the merits of one development system over another, particularly if the
quality of the development tools is either unknown, or suspect?


I guess that this is why some shops pick a vendor, and then stick with that
vendor through good times and bad, rather than have to figure these things
out on every new hardware/OS platform.
Chewey, get us outta here!


kaleb@mars.jpl.nasa.gov Jet Propeller Labs
Kaleb Keithley





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.