Path: utzoo!telly!ddsw1!lll-winken!killer!texbell!bigtex!natinst!cs.utexas.edu!tut.cis.ohio-state.edu!UCSCI.UCSC.EDU!dsgn047
From: dsgn047@UCSCI.UCSC.EDU (10017047)
Newsgroups: gnu.gcc.bug
Subject: GCC 1.30 complaints
Message-ID: <8810220131.AA00312@ucsci.ucsc.edu>
Date: 22 Oct 88 01:31:17 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 32

Most of these aren't really bugs, but I think they should be reported
anyway.

1)  The infamous prototyping bug (you know, the one where you prototype a
function, and then declare it old-style?):  I will, for the moment, accept
rms' reasons why it does this, but only until I have enough time to hack
the code a bit.  Microsoft C (gack, I know) does *not* have this problem,
and I'm somewhat curious why (I'll look into it), and I'm sure all the
people who program (or have access to) GCC can certainly outprogram the
people at Microsoft 8-).

2)  Loop optimization.  GCC 1.30 does *not* get rid of empty for loops;
does anybody know why? (I.e., 'for (a=0;a<100;a++);' is executed in its
entirety.)

3)  Optimization with floating-point numbers.  I did a little 'max' routine,
returning the greater of two floating point numbers, and then caused GCC to
inline it.  When I called 'max(1.2,3.4),' it actually did the compare.
If I changed the floating-point numbers to integers (and changed the test
numbers accordingly), it *knew* which of the larger were.  Why the
inconsistency?  This is, of course, on GCC 1.30, on a VAX running 4.3.

So that I don't sound snotty, I am, of course, very impressed with GCC, and
most/all of these were found when I was comparing GCC to MS C running under
XENIX(tm) (MSC 4.5ish for the '386, 5.1 for the '286), and GCC does win in
some circumstances (MSC cannot inline, and boy is that nice at times).

Sean.
--------------------
Sean Eric Fagan
seanf@sco[.COM?]
or (temporarily) dsgn047@ucsci.ucsc.edu
"Batch jobs?  We don' need no steenkin' batch jobs!"