[unix-pc.general] Gcc 1.30 loses in battle with C-TeX 2.21

brant@manta.pha.pa.us (Brant Cheikes) (11/08/88)

I tried putting gcc 1.30 "through its paces" by using it to build the
latest version of C-TeX (2.21); the results aren't good.  The gcc I'm
using successfully compiled itself, but when I used it to compile
tangle in the texware area, it produced an executable that ran but
didn't work right.  Leaving the -O flag off gcc's command line
produced a proper tangle, but one that was 17% larger than that
produced by the stock compiler WITH optimization.  Similar results
were had for building triptex: gcc's optimized version didn't pass the
trip test, the non-optimized version passed fine, but was 14% larger
than the one produced with the stock ccom and optim (UNIX 3.51).  There
was a speed degradation corresponding to the increase in size.

So right now I don't see the benefit of gcc.  As long as its optimizer
is broken, the stock cc wins.  I should point out that the
dysfunctional optimized gcc-produced executable for triptex was about
15% SMALLER than the stock-cc optimized version.  And it did the wrong
thing much faster than the stock-cc version did the right thing.
-- 
Brant Cheikes
University of Pennsylvania
Department of Computer and Information Science
Internet: brant@manta.pha.pa.us, UUCP: bpa!manta!brant

alex@umbc3.UMD.EDU (Alex S. Crain) (11/09/88)

In article <443@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
>I tried putting gcc 1.30 "through its paces" by using it to build the
>latest version of C-TeX (2.21); the results aren't good.

	I remember this being a problem with C-tex, not gcc. GCC does fancy
register allocation, which can confuse programs that assume that data will be
stored on the stack (like setjmp/longjmp). This issue (C-tex) came over 
the info-gcc mailing list last month, and the result was fixes for C-tex. I
confess that I didn't pay much attention to the discussion, other than casual
interest, so I don't remember the name of the offending C-tex code.

-- 
					:alex.
					Systems Programmer
nerwin!alex@umbc3.umd.edu		UMBC
alex@umbc3.umd.edu

tkacik@rphroy.UUCP (Tom Tkacik) (11/10/88)

In article <443@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
>I tried putting gcc 1.30 "through its paces" by using it to build the
>latest version of C-TeX (2.21); the results aren't good.  The gcc I'm
>didn't work right.  Leaving the -O flag off gcc's command line
>produced a proper tangle, but one that was 17% larger than that
>produced by the stock compiler WITH optimization.  Similar results
>
>So right now I don't see the benefit of gcc.  As long as its optimizer
>is broken, the stock cc wins.  I should point out that the
>dysfunctional optimized gcc-produced executable for triptex was about
>15% SMALLER than the stock-cc optimized version.  And it did the wrong
>thing much faster than the stock-cc version did the right thing.
>-- 
>Brant Cheikes

That's interesting.  I have version gcc-1.28.  On this version, it appears
that without optimization, it generates bad code.  But with optimization
turned on it works just fine (so far, fingers crossed :-)).  And the code
size is smaller than with the stock pcc.  With opimization turned on,
the code is smaller than for pcc, while when it is turned off, as Brant
noticed, the code size is larger.  But that's what the GCC manual says
will happen.

I am just glad that the one I have has a working optimizer.  I do not really
care if it does not work without it,  I will just use pcc for that.

Does anyone have a version of GCC running on a 3b1 that works both
with the optimizer, without it?

---
Tom Tkacik
GM Research Labs,  Warren MI
{umix, uunet!edsews}!rphroy!megatron!tkacik