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.
Casts as lvalue have been deprecated already in GCC 3.4 and removed in 4.0, see http://gcc.gnu.org/gcc-4.0/changes.html. http://gcc.gnu.org/gcc-3.4/changes.html documents how the code should be fixed. As you haven't provided any details on what exactly doesn't compile in eterm, I can't comment on it. Also, not sure why you are trying exactly 3.3.3, last 3.3.x release was 3.3.6.
I think it's insane that GCC 4.1 can not compile a relatively recent GCC version, such as GCC 3.3, but that is not your fault. Thanks for the quick help.