Re: Phase 1 of gcc-in-cxx now complete

[Richard Guenther]

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)

[Eric Botcazou]

> 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)

[Laurent GUERBY]

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)

[Eric Botcazou]

> 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)

[Laurent GUERBY]

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)

[Laurent GUERBY]

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

[Daniel Berlin]

>
> 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

[Robert Dewar]

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)

[Paolo Bonzini]

"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

[Adam Nemet]

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

[David Edelsohn]

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

[Sebastian Pop]

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

[kernel mailz]

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

[H.J. Lu]

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

[Ian Lance Taylor]

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

[Jerry Quinn]

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