Re: Phase 1 of gcc-in-cxx now complete
On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylor wrote: > Matt writes: > >>> * Develop some trial patches which require C++, e.g., convert VEC to >>> std::vector. >> >> Do you have any ideas for the easiest starting points? Is there >> anywhere that is decently self-contained, or will if have to be a big >> bang? > > Thanks for your interest. > > I think the one I mentioned--converting VEC to std::vector--is a good > starting point. This is the interface in vec.h. > > Another easy starting point would be converting uses of htab_t to type > safe C++ hash tables, e.g., std::tr1:;unordered_map. Here portability > suggests the ability to switch to different hash table implementations; > see gold/gold.h in the GNU binutils for one way to approach that. > > Another easy starting point is finding calls to qsort and converting > them to std::sort, which typically leads to code which is larger but > runs faster. > > Longer term, we know that memory usage is an issue in gcc. In the old > obstack days, we had a range of obstacks with different lifespans, so we > could create RTL with a temporary lifetime which was given a longer > lifetime when needed. We got away from that because we spent far too > much time chasing bugs in which RTL should have been saved to a longer > lifetime but wasn't. However, that model should permit us to run with > significantly less memory, which would translate to less compile time. > I think we might be able to do it by implementing a custom allocator, > such as a pool allocator which permits allocating different sizes of > memory, and never frees memory. Then the tree class could take an > allocator as a template parameter. Then we would provide convertors > which copied the tree class to a different allocation style. Then, for > example, fold-const.c could use a temporary pool which lived only for > the length of the call to fold. If it returned a new value, the > convertor would force a copy out of the temporary pool. If this works > out, we can use type safety to enforce memory discipline, use > significantly less memory during compilation, and take a big step toward > getting rid of the garbage collector. All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? That said - I was more expecting to re-write the existing vec.h to C++ to avoid this GC vs. non-GC use differences. Also as the standard library uses a very inefficient allocator by default, should we for example switch from bitmap to an equivalend standard library container. IMHO we should at least try without the standard library for a start, fixing the GTY machinery. Richard.
Re: Phase 1 of gcc-in-cxx now complete (Ada)
> Interesting. I've been testing my -Wc++-compat patches with full > bootstraps including Ada, but I just looked at my make log and it does > indeed appear that -Wc++-compat doesn't make it onto the Ada files. > > It seems to be because of this line in ada/gcc-interface/Make-lang.in: > > ada-warn = $(ADA_CFLAGS) $(WERROR) > > The other languages use > > DIR-warn = $(STRICT_WARN) > > which is what brings in -Wc++-compat. I get -Wc++-compat warnings though: /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c: In function 'substitute_in_type': /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7865:8: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7886:4: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7894:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7907:4: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7911:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7917:7: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7918:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7921:34: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7938:2: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7947:9: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7960:2: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7992:33: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:8008:9: warning: identifier 'new' conflicts with C++ keyword but they don't stop the build because -Werror is not passed. That needs to be fixed first. -- Eric Botcazou
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote: > Arnaud Charlet writes: > > >> Switching gnatbind to generate Ada if there's nothing against > >> it might be a better solution since stage1 uses the system gnatbind, so > >> a patch to current gnatbind will not help (unless we push it to branches > >> and tell user to install a fairly recent gnatbind first). > > > > This does create a bootstrap incompatibility/issue indeed, interesting. > > Yet another alternative would be to use a C compiler to compile the binder > > generated file during bootstrap. > > Yes, I think that either compiling with a C compiler, or generating Ada > bindings, would be the best approach here. Switching gnatbind to generate Ada during bootstrap and with a mostly mechanical patch adding "#ifdef __cplusplus / extern C" where needed to honor matching "pragma Import/Export (C, xxx)" in Ada code I now get all three stages and gnatlib to build successfully on the branch. There was one other C/C++ compat issue: wrong code generated in gcc/ada/gcc-interface/utils.c and Andrew Pinski suggested the solution on IRC: @@ -4861,7 +4861,7 @@ va_start (list, n); for (i = 0; i < n; ++i) { - builtin_type a = va_arg (list, builtin_type); + builtin_type a = (builtin_type)va_arg (list, int); t = builtin_types[a]; if (t == error_mark_node) goto egress; This was the only va_arg usage, may be we should apply it on trunk too as the patched version is supposed to work for both C and C++. For toplevel gnattools I have a link issue since the LINKER variable used in the gcc subdir is not passed at toplevel, I'm currently trying wether passing LINKER=$(CXX) will do but I'm not sure that we really want here. I will submit the gnatbind switch to Ada patch separately for review on trunk after testing completes. Hopefully there seem to be no major issue in having Ada working on the gcc-in-cxx branch. Sincerely, Laurent
Re: Phase 1 of gcc-in-cxx now complete (Ada)
> This was the only va_arg usage, may be we should apply it on trunk too > as the patched version is supposed to work for both C and C++. Yes, but I'm testing a patch for trunk with more changes. -- Eric Botcazou
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote: > > This was the only va_arg usage, may be we should apply it on trunk too > > as the patched version is supposed to work for both C and C++. > > Yes, but I'm testing a patch for trunk with more changes. For reference here is my current draft patch to gcc-in-cxx branch, it completes make bootstrap including gnattools, check running. Laurent Index: gcc/ada/adadecode.h === --- gcc/ada/adadecode.h (revision 148953) +++ gcc/ada/adadecode.h (working copy) @@ -29,6 +29,11 @@ * * / + +#ifdef __cplusplus +extern "C" { +#endif + /* This function will return the Ada name from the encoded form. The Ada coding is done in exp_dbug.ads and this is the inverse function. see exp_dbug.ads for full encoding rules, a short description is added @@ -51,3 +56,8 @@ function used in the binutils and GDB. Always consider using __gnat_decode instead of ada_demangle. Caller must free the pointer returned. */ extern char *ada_demangle (const char *); + + +#ifdef __cplusplus +} +#endif Index: gcc/ada/sysdep.c === --- gcc/ada/sysdep.c(revision 148953) +++ gcc/ada/sysdep.c(working copy) @@ -32,6 +32,10 @@ /* This file contains system dependent symbols that are referenced in the GNAT Run Time Library */ +#ifdef __cplusplus +extern "C" { +#endif + #ifdef __vxworks #include "ioLib.h" #include "dosFsLib.h" @@ -938,3 +942,7 @@ return 0; } } + +#ifdef __cplusplus +} +#endif Index: gcc/ada/targext.c === --- gcc/ada/targext.c (revision 148953) +++ gcc/ada/targext.c (working copy) @@ -33,6 +33,10 @@ /* extension for object and executable files. It is used by the compiler, */ /* binder and tools. */ +#ifdef __cplusplus +extern "C" { +#endif + #include "system.h" #include "coretypes.h" #include "tm.h" @@ -48,3 +52,8 @@ const char *__gnat_target_object_extension = TARGET_OBJECT_SUFFIX; const char *__gnat_target_executable_extension = TARGET_EXECUTABLE_SUFFIX; const char *__gnat_target_debuggable_extension = TARGET_EXECUTABLE_SUFFIX; + + +#ifdef __cplusplus +} +#endif Index: gcc/ada/s-oscons-tmplt.c === --- gcc/ada/s-oscons-tmplt.c(revision 148953) +++ gcc/ada/s-oscons-tmplt.c(working copy) @@ -79,6 +79,11 @@ ** **/ + +#ifdef __cplusplus +extern "C" { +#endif + #include #include #include @@ -1307,8 +1312,14 @@ #endif + /* end System.OS_Constants; */ } + + +#ifdef __cplusplus + } +#endif Index: gcc/ada/env.c === --- gcc/ada/env.c (revision 148953) +++ gcc/ada/env.c (working copy) @@ -29,6 +29,11 @@ * * / + +#ifdef __cplusplus +extern "C" { +#endif + #ifdef IN_RTS #include "tconfig.h" #include "tsystem.h" @@ -313,3 +318,7 @@ clearenv (); #endif } + +#ifdef __cplusplus +} +#endif Index: gcc/ada/final.c === --- gcc/ada/final.c (revision 148953) +++ gcc/ada/final.c (working copy) @@ -29,6 +29,11 @@ * * / + +#ifdef __cplusplus +extern "C" { +#endif + extern void __gnat_finalize (void); /* This routine is called at the extreme end of execution of an Ada program @@ -40,3 +45,8 @@ __gnat_finalize (void) { } + + +#ifdef __cplusplus +} +#endif Index: gcc/ada/init.c === --- gcc/ada/init.c (revision 148953) +++ gcc/ada/init.c (working copy) @@ -38,6 +38,11 @@ installed by this file are used to catch the resulting signals that come from these probes failing (i.e. touching protected pages). */ + +#ifdef __cplusplus +extern "C" { +#endif + /* This file should be kept synchronized with 2sinit.ads, 2sinit.adb, s-init-ae653-cert.adb and s-init-xi-sparc.adb. All these files implement the required functionality for different targets. */ @@ -2319,3 +2324,7 @@ } #endif + +#ifdef __cplusplus +} +#endif Index: gcc/ada/xsnamest.adb === --- gcc/ada/xsnamest.adb(revision 148953) +++ gcc/ada/xsnamest.adb(working copy) @@ -194,6 +194,10 @@ Create (OutB, Out_File, "snames.nb"); Create (OutH, Out_File, "snames.nh");
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Sat, 2009-06-27 at 13:51 +0200, Laurent GUERBY wrote: > On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote: > > > This was the only va_arg usage, may be we should apply it on trunk too > > > as the patched version is supposed to work for both C and C++. > > > > Yes, but I'm testing a patch for trunk with more changes. > > For reference here is my current draft patch to gcc-in-cxx branch, > it completes make bootstrap including gnattools, check > running. During make check gnat.dg was clean but there were two FAIL in ACATS: === acats tests === FAIL: c940005 FAIL: c940007 === acats Summary === # of expected passes2313 # of unexpected failures2 Native configuration is x86_64-unknown-linux-gnu === gnat Summary === # of expected passes659 # of expected failures 5 ,.,. C940005 ACATS 2.5 09-06-27 14:16:44 C940005 Check internal calls of protected functions and procedures. * C940005 Unexpected paths taken. C940005 FAILED . ,.,. C940007 ACATS 2.5 09-06-27 14:16:46 C940007 Check internal calls of protected functions and procedures in objects declared as a type. * C940007 Unexpected paths taken. C940007 FAILED . I haven't investigated those FAIL. make install worked too and the installed compiler is able to compile and link small Ada programs. I'll let maintainers comment on what we should do and with what timing. Sincerely, Laurent
Re: Phase 1 of gcc-in-cxx now complete
> > All that above said - do you expect us to carry both vec.h (for VEC in > GC memory) and std::vector (for VECs in heap memory) (and vec.h > for the alloca trick ...)? Or do you think we should try to make the GTY > machinery C++ aware and annotate the standard library (ick...)? Since the containers have mostly standard iterators, i'm not sure we have to do much to the standard library. Simply require a set of iterators with the right properties exist and generate code that depends on this. If you make your own container, you have to implement the iterators.
Re: Phase 1 of gcc-in-cxx now complete
Daniel Berlin wrote: All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? Since the containers have mostly standard iterators, i'm not sure we have to do much to the standard library. Simply require a set of iterators with the right properties exist and generate code that depends on this. If you make your own container, you have to implement the iterators. Shouldn't this be a new thread, or is this really part of phase 1?
Re: Phase 1 of gcc-in-cxx now complete (Ada)
"CC=../../xgcc -B../../" \ + "LINKER=$(CXX)" \ "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \ I think you should rather do "CC=../../xgcc -B../../" \ + "CXX=../../g++ -B../../" \ "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \ + "CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS)" \ and copy the setting of COMPILER and LINKER from gcc/Makefile.in into gcc/ada/gcc-interface/Makefile.in: ENABLE_BUILD_WITH_CXX = @ENABLE_BUILD_WITH_CXX@ ifneq ($(ENABLE_BUILD_WITH_CXX),yes) COMPILER = $(CC) COMPILER_FLAGS = $(CFLAGS) LINKER = $(CC) LINKER_FLAGS = $(CFLAGS) else COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) LINKER = $(CXX) LINKER_FLAGS = $(CXXFLAGS) endif Paolo
Re: Phase 1 of gcc-in-cxx now complete
Ian Lance Taylor writes: > I would like to encourage people to try using --enable-build-with-cxx in > other configuration--other bootstraps, cross-compilers--to see how well > it works. Please let me know if you run into problems that you don't > know how, or don't have time, to fix. MIPS bootstraps fine with --enable-build-with-cxx: http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg02323.html I don't know if the new failures are related to C++; I will do a C build later and compare. Ian, thanks for your C++ work! Adam
Re: Phase 1 of gcc-in-cxx now complete
On Thu, Jun 25, 2009 at 4:32 PM, Ian Lance Taylor wrote: > I would like to encourage people to try using --enable-build-with-cxx in > other configuration--other bootstraps, cross-compilers--to see how well > it works. Please let me know if you run into problems that you don't > know how, or don't have time, to fix. I tried bootstrap with AIX. Because AIX static libstdc++ requires libsupc++, the search path for that library in the build directory needs to be on the link line. Manually adding that directory allows GCC on AIX to get through stage3 bootstrap. There are two other problems / annoyances independent of AIX: 1) All of the multilibs for libstdc++ are configured and built during bootstrap. This always has been the case for libgcc, but it was not as much of an inconvenience. 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite fails in CXX mode. David
Re: Phase 1 of gcc-in-cxx now complete
On Sat, Jun 27, 2009 at 11:51, David Edelsohn wrote: > 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite > fails in CXX mode. I did applied the patches from Ian to the cloog-ppl git. The git version should compile with a C++ compiler. Sebastian
Inline Assembly queries
Hello All the gurus, I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc There are a few queries 1. asm volatile or simply asm produce the same assembly code. Tried with a few examples but didnt find any difference by adding volatile with asm 2. Use of "memory" and clobbered registers. "memory" - a. announce to the compiler that the memory has been modified b. this instruction writes to some memory (other than a listed output) and GCC shouldn’t cache memory values in registers across this asm. I tried with stw and stwcx instruction, adding "memory" has no effect. Is there any example scenerio where gcc would generate different assembly by adding / removing "memory" ? -TZ
The Linux binutils 2.19.51.0.11 is released
Main changes from binutils 2.19.51.0.10: Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337. Add STB_GNU_UNIQU support. H.J. --- This is the beta release of binutils 2.19.51.0.11 for Linux, which is based on binutils 2009 0627 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been applied and in what order they have been applied. Starting from the 2.18.50.0.4 release, the x86 assembler no longer accepts fnstsw %eax fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged. Please use fnstsw %ax Starting from the 2.17.50.0.4 release, the default output section LMA (load memory address) has changed for allocatable sections from being equal to VMA (virtual memory address), to keeping the difference between LMA and VMA the same as the previous output section in the same region. For .data.init_task : { *(.data.init_task) } LMA of .data.init_task section is equal to its VMA with the old linker. With the new linker, it depends on the previous output section. You can use .data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) } to ensure that LMA of .data.init_task section is always equal to its VMA. The linker script in the older 2.6 x86-64 kernel depends on the old behavior. You can add AT (ADDR(section)) to force LMA of .data.init_task section equal to its VMA. It will work with both old and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and above is OK. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.19.51.0.11 to hjl.to...@gmail.com and http://www.sourceware.org/bugzilla/ Changes from binutils 2.19.51.0.10: 1. Update from binutils 2009 0627. 2. Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337. 3. Add STB_GNU_UNIQU support. 4. Fix objcopy on empty file. PR 10321. 5. Fix debug section for PE-COFF. 6. Suport build with gcc 4.5.0. 7. Improve arm support. 8. Improve ppc support. 9. Improve m10300 support. 10. Improve mep support. 11. Improve MacOS support. 12. Improve gold support. Changes from binutils 2.19.51.0.9: 1. Update from binutils 2009 0618. 2. Update STT_GNU_IFUNC symbol support. PR 10269/10270. 3. Fix an assembler CFI bug. PR 10255. 4. Improve objdump. PR 10263/10288 5. Improve readelf. 6. Improve arm support. 7. Improve moxie support. 8. Improve spu support. 9. Improve vax support. 10. Improve COFF/PE support. 11. Improve MacOS support. Changes from binutils 2.19.51.0.8: 1. Update from binutils 2009 0606. 2. Update STT_GNU_IFUNC symbol support. Changes from binutils 2.19.51.0.7: 1. Update from binutils 2009 0603. 2. Fix STT_GNU_IFUNC symbol with pointer equality. Changes from binutils 2.19.51.0.6: 1. Update from binutils 2009 0601. 2. Update STT_GNU_IFUNC support. PR 10205. 3. Fix x86 asssembler Intel syntax regression with '$'. PR 10198. Changes from binutils 2.19.51.0.5: 1. Update from binutils 2009 0529. 2. Rewrite STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE linker support for STT_GNU_IFUNC symbols in shared library, dynamic executable and static executable. 3. Add plugin support. 4. Improve spu support. Changes from binutils 2.19.51.0.4: 1. Update from binutils 2009 0525. 2. Add STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE support to assembler and linker. 3. Add LD_AS_NEEDED support to linker. 4. Remove AMD SSE5 support. 5. A new Intel syntax parser in x86 assembler. 6. Add DWARF discriminator support. 7. Add --64 support for x86 PE/COFF assembler. 8. Support common symbol with alignment for PE/COFF. 9. Improve gold support. 10. Improve arm support.
Re: Phase 1 of gcc-in-cxx now complete
Richard Guenther writes: > All that above said - do you expect us to carry both vec.h (for VEC in > GC memory) and std::vector (for VECs in heap memory) (and vec.h > for the alloca trick ...)? Or do you think we should try to make the GTY > machinery C++ aware and annotate the standard library (ick...)? I expect us to write a GC allocator, and use that with std::vector. This will require more hooks into the GC code, but I think it is doable. > IMHO we should at least try without the standard library for a start, > fixing the GTY machinery. If we can't write a GC allocator, then I agree. Ian
Exploring gcc-in-cxx compiler build requirements
Hi, all, I just tried to build gcc-in-cxx with some older gcc compilers on x86_64 linux. This is Debian testing, with 4.3.3 as the system compiler. Here's what I've gotten so far: 2.95.3 Doesn't support x86_64 3.0.4 Doesn't support x86_64 3.1.1 Fails to bootstrap 3.2.3 Fails to bootstrap Both 3.1.1 and 3.2.3 fail to bootstrap with the following error: make[1]: Entering directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' gcc -c -DIN_GCC--std=gnu89 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -I. -I../../../gcc-3.2.3/gcc -I../../../gcc-3.2.3/gcc/. -I../../../gcc-3.2.3/gcc/config -I../../../gcc-3.2.3/gcc/../include ../../../gcc-3.2.3/gcc/read-rtl.c -o read-rtl.o In file included from ../../../gcc-3.2.3/gcc/read-rtl.c:24: ../../../gcc-3.2.3/gcc/rtl.h:125: warning: type of bit-field ‘code’ is a GCC extension ../../../gcc-3.2.3/gcc/rtl.h:128: warning: type of bit-field ‘mode’ is a GCC extension ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘fatal_with_file_and_line’: ../../../gcc-3.2.3/gcc/read-rtl.c:62: warning: traditional C rejects ISO C style function definitions ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘read_rtx’: ../../../gcc-3.2.3/gcc/read-rtl.c:662: error: lvalue required as increment operand make[1]: *** [read-rtl.o] Error 1 make[1]: Leaving directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' make: *** [all-gcc] Error 2 3.3.6 old compiler builds. branch bootstrap fails with: make[3]: Entering directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' g++ -c -g -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber../.././gcc/c-lang.c -o c-lang.o In file included from /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/iosfwd:46, from /usr/include/gmp-x86_64.h:24, from /usr/include/gmp.h:59, from ../../gcc/double-int.h:24, from ../../gcc/tree.h:30, from ../../gcc/c-lang.c:27: /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/x86_64-unknown-linux-gnu/bits/c++locale.h:61:40: attempt to use poisoned "malloc" make[3]: *** [c-lang.o] Error 1 make[3]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make: *** [all] Error 2 I updated the system gmp to 4.2.3, so the C++ fix is present in the header. I'm configuring and bootstrapping with the 3.3.6 install at the head of the path. Maybe building with the CXX and CC explicitly specified would work better here. I didn't run the test suite on the 3.3.6 build, so it's possible it didn't build correctly. gcc 3.4.6 successfully bootstraps the branch with all default languages. Jerry