Description of problem:

The gcc version shipped with Fedora Core 5 fails to compile a large number of
programs because of stricter code parsing rules. Most notably gcc 3.3 no longer
compiles. Other programs include eterm.

When compiling GCC, the following output is produced:

gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long   -DHAVE_CONFIG_H
-DGENERATOR_FILE    -I. -I. -I. -I./. -I./config -I./../include ./read-rtl.c -o
read-rtl.o
In file included from ./read-rtl.c:24:
./rtl.h:132: warning: type of bit-field ‘code’ is a GCC extension
./rtl.h:135: warning: type of bit-field ‘mode’ is a GCC extension
./read-rtl.c: In function ‘fatal_with_file_and_line’:
./read-rtl.c:53: warning: traditional C rejects ISO C style function definitions
./read-rtl.c: In function ‘read_rtx’:
./read-rtl.c:653: error: invalid lvalue in increment

The line in question (653) is a macro that uses a lot of spiffy macro magic. The
eterm problem is caused by similar code. 


Version-Release number of selected component (if applicable): 

4.1.0-3

How reproducible:

Always

Steps to Reproduce:
1. Download and extract sourcecode for gcc 3.3.3
2. Run ./configure
3. Run make
  
Actual results:

Compilation fails

Expected results: 

Compilation produces a working compiler


Additional info:

This bug has turned my life into a Kafka-esque nigtmare. I try to compile eterm
in order to check on a bugreport for one of my projects,
http://roo.no-ip.org/fish. Eterm doesn't compile because of this bug. I figure
the compiler is to blame, so I try to compile my own gcc version. Gcc doesn't
compile because of this bug. I try to compile eterm on Fedora Core 4. The
configure script for libast fails during a cpp sanity check. I try to report
this bug on bugzilla. Bugzilla gives me a '500 - Internal server error'. I try
again later. Bugzilla bug search tool hangs.

Please help me.