[Bug bootstrap/50237] New: [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[Bug bootstrap/50237] New: [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

             Bug #: 50237
           Summary: [4.7 regression] comparison failure caused by
                    HAVE_INITFINI_ARRAY check
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ebotcazou@gcc.gnu.org
              Host: x86_64-suse-linux
            Target: x86_64-suse-linux
             Build: x86_64-suse-linux


I have had a bootstrap comparison failure for days on x86-64/Linux:

libcpp/lex.o differs

It turns out that stage3 has

  6 .init_array   00000008  0000000000000000  0000000000000000  00003d20  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

but stage2 has

  6 .ctors        00000008  0000000000000000  0000000000000000  00003d20  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

That isn't surprising because HAVE_INITFINI_ARRAY isn't uniform:

eric@hermes:~/build/gcc/native> grep HAVE_INITFINI_ARRAY stage1-gcc/auto-host.h 
/* #undef HAVE_INITFINI_ARRAY */
eric@hermes:~/build/gcc/native> grep HAVE_INITFINI_ARRAY prev-gcc/auto-host.h
#define HAVE_INITFINI_ARRAY 1

i.e. despite http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00659.html the check
is still applied to the host compiler, not to the target.  The base compiler is
the system compiler on OpenSuSE 11.0 and the check doesn't pass for it:

eric@hermes:~/build/gcc/native> gcc -o t t.c
eric@hermes:~/build/gcc/native> ./t
Aborted

The compiler is configured with

eric@hermes:~/build/gcc/native> gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc/configure x86_64-suse-linux
--prefix=/home/eric/install/gcc
--with-as=/home/eric/build/binutils/native/gas/as-new
--with-ld=/home/eric/build/binutils/native/ld/ld-new
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-checking=yes,rtl --enable-__cxa_atexit --disable-nls
--disable-libmudflap
Thread model: posix
gcc version 4.7.0 20110830 (experimental) [trunk revision 178287] (GCC)


A workaround would be to get rid of the __attribute__((constructor)) in lex.c
but someone should sit down and write a correct HAVE_INITFINI_ARRAY check.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at gcc dot gnu.org
   Target Milestone|---                         |4.7.0

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|hjl at gcc dot gnu.org      |hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-30 13:40:54 UTC ---
HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
independent of compiler.  Which GCC does OpenSuSE 11.0 have?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-30 13:50:28 UTC ---
> HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> independent of compiler.

AFAICS it doesn't, it compiles everything with the host compiler, which will
use in particular the old binutils.  See by contrast various tests in
configure.ac that really check the features of the new binutils.

> Which GCC does OpenSuSE 11.0 have?

Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE
Linux)

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-30 13:57:46 UTC ---
(In reply to comment #2)
> > HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> > independent of compiler.
> 
> AFAICS it doesn't, it compiles everything with the host compiler, which will
> use in particular the old binutils.  See by contrast various tests in
> configure.ac that really check the features of the new binutils.
> 

How is the different binutils in stage 1/2/3? Can you use
the same binutils in stage 1/2/3?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-30 14:09:08 UTC ---
Only stage2/3 binutils need to be the same and those are relevant for
feature tests.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-30 14:23:05 UTC ---
(In reply to comment #4)
> Only stage2/3 binutils need to be the same and those are relevant for
> feature tests.

How does stage 2 binutils fail the test?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-30 15:00:54 UTC ---
> How does stage 2 binutils fail the test?

It doesn't.  Let me explain:

  - during stage1, the check is made with the host compiler, i.e. the base
compiler, so the old binutils are used and the check fails, that's why we have

/* #undef HAVE_INITFINI_ARRAY */

in stage1-gcc/auto-host.h.  This means that the stage1 compiler doesn't have
the support.  Since this compiler is used to compile stage2 libcpp/lex.o, the
file gets the .ctors section.

  - during stage2, the check is made with the host cmpiler, i.e. the stage 1
compiler, so the new binutils (--with-as=, --with-ld) are used and the check
succeeds, that's why we have

#define HAVE_INITFINI_ARRAY 1

in stage2-gcc/auto-host.h.  This means that the stage2 compiler has the
support.
Since this compiler is used to compile stage3 libcpp/lex.o, the file gets the
.init_array section.


The fix is to turn the check into a target check, i.e. test the target
binutils.
See configure.ac:1884 and below.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-08-30 15:40:49 UTC ---
On Tue, 30 Aug 2011, ebotcazou at gcc dot gnu.org wrote:

> The fix is to turn the check into a target check, i.e. test the target
> binutils.
> See configure.ac:1884 and below.

And a proper target check should not be testing execution of the generated 
code to work properly with cross compilation.  The following are 
unconditionally safe:

* Testing the target triplet.  In particular, use ACX_ELF_TARGET_IFELSE 
(config/elf.m4) to eliminate non-ELF targets.

* Testing uses of the assembler and linker, and using target objdump (when 
using GNU binutils) to examine the result, as long as the linker uses do 
not require any target libraries to be present.

* Examining target headers (see the code checking for glibc versions in 
$target_header_dir/features.h).

The first two should be able to tell if the assembler and linker have all 
the required features.  init_array and fini_array are standard ELF 
features so I think the default should be to assume they will work on the 
target (if ELF) unless a reason arises to blacklist particular targets.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-30 15:55:51 UTC ---
The main issue is mixing input .ctors sections with .init_array sections
to generate the single output .init_array section.  Not all linkers support
it even if they support .init_array section.  How should we properly
test this?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-30 15:56:45 UTC ---
In the meantime, you can use --enable-initfini-array/--disable-initfini-array
to work around this.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-08-30 16:39:39 UTC ---
On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:

> The main issue is mixing input .ctors sections with .init_array sections
> to generate the single output .init_array section.  Not all linkers support
> it even if they support .init_array section.  How should we properly
> test this?

Is it not possible to link (with -r, maybe) objects and examine the output 
with target objdump to see if .ctors sections are still present?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 04:21:53 UTC ---
(In reply to comment #10)
> On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
> 
> > The main issue is mixing input .ctors sections with .init_array sections
> > to generate the single output .init_array section.  Not all linkers support
> > it even if they support .init_array section.  How should we properly
> > test this?
> 
> Is it not possible to link (with -r, maybe) objects and examine the output 
> with target objdump to see if .ctors sections are still present?

"ld -r" won't/shouldn't combine different sections.  We
can use ld to generate executables.  How can we check if
input .ctors.* and .init_array.* sections are placed
in the right order?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-08-31 15:27:44 UTC ---
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
> 
> --- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 04:21:53 UTC ---
> (In reply to comment #10)
> > On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
> > 
> > > The main issue is mixing input .ctors sections with .init_array sections
> > > to generate the single output .init_array section.  Not all linkers support
> > > it even if they support .init_array section.  How should we properly
> > > test this?
> > 
> > Is it not possible to link (with -r, maybe) objects and examine the output 
> > with target objdump to see if .ctors sections are still present?
> 
> "ld -r" won't/shouldn't combine different sections.  We
> can use ld to generate executables.  How can we check if
> input .ctors.* and .init_array.* sections are placed
> in the right order?

Arrange for the contents to have appropriate text values you can check for 
with grep (or if you wish a custom C program to run on the build system to 
examine ELF structures - only ELF needs to be considered for this, after 
all, and I think at this point you may even be able to rely on having 
libiberty already built for the build system, complete with the 
simple-object-elf code).

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 15:44:02 UTC ---
(In reply to comment #12)
> 
> Arrange for the contents to have appropriate text values you can check for 
> with grep (or if you wish a custom C program to run on the build system to 
> examine ELF structures - only ELF needs to be considered for this, after 
> all, and I think at this point you may even be able to rely on having 
> libiberty already built for the build system, complete with the 
> simple-object-elf code).

.init_array section is an array of pointers. How do you grep it?

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-08-31 15:46:46 UTC ---
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
> 
> --- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 15:44:02 UTC ---
> (In reply to comment #12)
> > 
> > Arrange for the contents to have appropriate text values you can check for 
> > with grep (or if you wish a custom C program to run on the build system to 
> > examine ELF structures - only ELF needs to be considered for this, after 
> > all, and I think at this point you may even be able to rely on having 
> > libiberty already built for the build system, complete with the 
> > simple-object-elf code).
> 
> .init_array section is an array of pointers. How do you grep it?

You arrange for the pointers to be assigned values whose bytes happen to 
correspond to text (endian-independent text, ideally).  Just like using 
grep to determine target endianness or floating point format.

[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-02 18:09:41 UTC ---
(In reply to comment #14)
> > 
> > .init_array section is an array of pointers. How do you grep it?
> 
> You arrange for the pointers to be assigned values whose bytes happen to 
> correspond to text (endian-independent text, ideally).  Just like using 
> grep to determine target endianness or floating point format.

I couldn't find an uniform way to assign a fixed address to symbol
in a section which works for all ELF targets.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.7 regression] comparison |[4.7 regression] bootstrap
                   |failure caused by           |comparison failure for
                   |HAVE_INITFINI_ARRAY check   |libcpp/lex.o
           Severity|blocker                     |critical

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-03 09:31:22 UTC ---
The --disable-initfini-array workaround works fine so downgrading slightly.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2011-09/msg00223.htm
                   |                            |l

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-03 17:16:17 UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00223.html

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
                   |atches/2011-09/msg00223.htm |atches/2011-09/msg00668.htm
                   |l                           |l

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-10 14:45:40 UTC ---
The updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00668.html

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-suse-linux           |x86_64-suse-linux,
                   |                            |*-*-solaris2*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-10-04
                 CC|                            |ro at gcc dot gnu.org
               Host|x86_64-suse-linux           |x86_64-suse-linux,
                   |                            |*-*-solaris2*
     Ever Confirmed|0                           |1
              Build|x86_64-suse-linux           |x86_64-suse-linux,
                   |                            |*-*-solaris2*

--- Comment #19 from Rainer Orth <ro at gcc dot gnu.org> 2011-10-04 13:54:59 UTC ---
I observe exactly the same problem on Solaris 11/x86, especially with Go:

gcc/go/unsafe.o differs
gcc/go/lex.o differs
gcc/go/runtime.o differs
gcc/go/expressions.o differs
gcc/go/dataflow.o differs
gcc/go/ast-dump.o differs
gcc/go/go-gcc.o differs
gcc/go/import.o differs
gcc/go/go.o differs
gcc/go/export.o differs
gcc/go/go-optimize.o differs
gcc/go/go-dump.o differs
gcc/go/import-archive.o differs
gcc/go/gogo.o differs
gcc/go/statements.o differs
gcc/go/gogo-tree.o differs
gcc/go/types.o differs
gcc/go/parse.o differs

The bootstrap compiler is gcc 4.4.2 configured with gas 2.19 and Sun ld, while
I'm configuring with gas and gld 2.21.90 which have full
.init_array/.fini_array
support as required by H.J.'s check.

Initially, I tried make bootstrap4, assuming that the comparison of stage2 and
stage3 would be skipped in favour of the stage3/stage4 comparison (which works
ok), but unfortunately this is not the case.

  Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-22 17:21:38 UTC ---
HJ,

with binutils 2.22 now released, could you please work to get this
fixed?  IMO binutils releases need to work for bootstrapping gcc out of
the box without any workarounds on the part of the installer.

Thanks.
        Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 17:52:52 UTC ---
(In reply to comment #20)
> HJ,
> 
> with binutils 2.22 now released, could you please work to get this
> fixed?  IMO binutils releases need to work for bootstrapping gcc out of
> the box without any workarounds on the part of the installer.
> 

There is not much I can do when there are 2 binutils used.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-22 17:55:15 UTC ---
But this is the common case: you cannot expect or require the bootstrap
compiler to use the same linker as you configure with.  This is a
bootstrap failure which is going to get us much noise if not fixed.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 18:03:09 UTC ---
(In reply to comment #22)
> But this is the common case: you cannot expect or require the bootstrap
> compiler to use the same linker as you configure with.  This is a
> bootstrap failure which is going to get us much noise if not fixed.
> 

Have you tried the patch in comment 18?

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-23 15:27:22 UTC ---
> --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 18:03:09 UTC ---
> (In reply to comment #22)
>> But this is the common case: you cannot expect or require the bootstrap
>> compiler to use the same linker as you configure with.  This is a
>> bootstrap failure which is going to get us much noise if not fixed.
>> 
>
> Have you tried the patch in comment 18?

Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap
compiler needn't be gcc, thus may not understand -B, so the result would
be wrong even if you configure with gld 2.22.  I don't understand why
you go through so many contortions, full of unwarranted assumptions,
when a simple check for gld >= 2.22 (or 2.21.9x if absolutely necessary)
would do.  If other linkers gain the same support, the test can be
augmented accordingly.  I know this is ugly and real feature checks are
the preferred way, but they are notoriously hard to get right portably,
so many of them already go this route.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-23 16:42:43 UTC ---
(In reply to comment #24)
> > --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 18:03:09 UTC ---
> > (In reply to comment #22)
> >> But this is the common case: you cannot expect or require the bootstrap
> >> compiler to use the same linker as you configure with.  This is a
> >> bootstrap failure which is going to get us much noise if not fixed.
> >> 
> >
> > Have you tried the patch in comment 18?
> 
> Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap
> compiler needn't be gcc, thus may not understand -B, so the result would
> be wrong even if you configure with gld 2.22.  I don't understand why
> you go through so many contortions, full of unwarranted assumptions,
> when a simple check for gld >= 2.22 (or 2.21.9x if absolutely necessary)
> would do.  If other linkers gain the same support, the test can be
> augmented accordingly.  I know this is ugly and real feature checks are
> the preferred way, but they are notoriously hard to get right portably,
> so many of them already go this route.
> 

Checking linker version is inaccurate since this feature requires
support in assembler, linker as well as libc. We can disable it by'
default when 2 linkers are used.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-23 16:53:16 UTC ---
> Checking linker version is inaccurate since this feature requires
> support in assembler, linker as well as libc. We can disable it by'
> default when 2 linkers are used.

Then why not check those separately and combine the result.  It's
certainly more reliable than the current guesswork.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-23 17:15:58 UTC ---
(In reply to comment #26)
> > Checking linker version is inaccurate since this feature requires
> > support in assembler, linker as well as libc. We can disable it by'
> > default when 2 linkers are used.
> 
> Then why not check those separately and combine the result.  It's
> certainly more reliable than the current guesswork.
> 

This test uses the run-time test to check if .ctors and .init_array
input sections can be mixed.  Separate tests don't make much sense.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-24 17:44:03 UTC ---
> This test uses the run-time test to check if .ctors and .init_array
> input sections can be mixed.  Separate tests don't make much sense.

Would you care to elaborate why checking the versions resp. features of
the prerequisite components is not enough?

Btw., what libc is required?  I've successfully built and tested with
--enable-init-fini-array on Solaris 11 (with no glibc in sight),
provided I run a make bootstrap4 and ignore the comparison failure in
stage3.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-11-28 15:10:00 UTC ---
Created attachment 25937
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25937
gcc47-pr50237.patch

Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
either.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-28 15:40:32 UTC ---
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

... but doesn't help for the Go comparison failures.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #31 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-01 20:25:27 UTC ---
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

Right, I'd apply the patch in any case, this is a gratuitous portability issue.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-07 22:06:04 UTC ---
Author: jakub
Date: Wed Dec  7 22:05:59 2011
New Revision: 182090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182090
Log:
    PR bootstrap/50237
    * internal.h (_cpp_init_lexer): New prototype.
    * init.c (init_library): Call it.
    * lex.c (init_vectorized_lexer): Remove constructor attribute,
    add inline keyword.
    (HAVE_init_vectorized_lexer): Define.
    (_cpp_init_lexer): New function.

Modified:
    trunk/libcpp/ChangeLog
    trunk/libcpp/init.c
    trunk/libcpp/internal.h
    trunk/libcpp/lex.c

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #33 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-09 00:54:10 UTC ---
I now get this failure with gcc/go/go.o (and others) miscomparing.
I have a new version of binutils installed in the prefix but not currently in
the PATH.
stage2 uses ctors and stage3 uses init_array.

Now my work around is just to put the new binutils in the PATH but that should
not be needed.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #34 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-09 14:31:30 UTC ---
Another possible fix is to drop autodetecting the feature (defaulting to
the old behavior) and requiring --enable-init_array at configure time.

HJ, please work on this, this is a real blocker.  I prefer the explicit
configure argument way for 4.7, we can switch to autodetection in a later
release.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-17 16:00:44 UTC ---
Created attachment 26352
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26352
gcc47-pr50237.patch

Untested patch.  For ia64 I've kept it (hopefully) as is, for other targets
this
attempts to detect the missing linker support using as/ld/objdump.
There is no testing of the libc/dynamic linker though, what C libraries do
support .init_array/.fini_array properly?  For glibc I'd say at least all >=
2.4, since 2.4 removed altogether support for configurations where linker
didn't support .init_array, so perhaps we could AC_PREPROC_IFELSE and test
__GLIBC__ and __GLIBC_MINOR__ macros.  What other OSes support .init_array
properly and would like it be enabled by default when neither
--enable-initfini-array nor --disable-initfini-array is specified?

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 10:43:58 UTC ---
Author: jakub
Date: Thu Jan 19 10:43:54 2012
New Revision: 183299

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183299
Log:
    PR bootstrap/50237
    * config/initfini-array.h: Guard content of the header
    with #ifdef HAVE_INITFINI_ARRAY.
    * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file.
    Add initfini-array.h to tm_file here.
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker
    test.
    * config.gcc: Don't add initfini-array.h to tm_file here.
    * configure: Regenerated.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/acinclude.m4
    trunk/gcc/config.gcc
    trunk/gcc/config/initfini-array.h
    trunk/gcc/configure
    trunk/gcc/configure.ac

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 10:50:13 UTC ---
Rainer/Andrew, please test this in your configurations.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-19 16:08:44 UTC ---
> --- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 10:50:13 UTC ---
> Rainer/Andrew, please test this in your configurations.

I've just successfully completed i386-pc-solaris2.1[01] gas/gld
bootstraps without the previous --disable-initfini-array workaround.

Thanks for fixing this.

I'll check if support can unconditionally be enabled on Solaris if the
tools support it.

So far, ld -e 0 doesn't work:

ld: fatal: entry point symbol '0' is undefined

while omitting -e 0 gets a warning from gld:

gld-2.22: warning: cannot find entry symbol _start; defaulting to
0000000008048054

The latter is probably harmless, though, and we can just omit the -e 0
everwhere.

While gld does merge the .init_array.N/.fini_array.N sections, Sun ld
does not, so the test always fails if ld is in use.

(Recent?) Sun as on Solaris 10 and 11/x86 work, too.

On Solaris 11/SPARC, the test fails even with gas and gld 2.22:

> objdump -s -j .init_array conftest

conftest:     file format elf32-sparc-sol2

Contents of section .init_array:
 20054 48484848 44444444                    HHHHDDDD      

Still need to check why.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:17:29 UTC ---
(In reply to comment #38)
> So far, ld -e 0 doesn't work:

Well, if no Sun ld handles the section mixing right, it doesn't matter that
much.  We could just:
  .text
  .globl _start
_start:
at the end of the assembly otherwise.

> (Recent?) Sun as on Solaris 10 and 11/x86 work, too.

It will still not default to --enable-initfini-array there, because of the
glibc version check.  Does Solaris dynamic linker handle .init_array etc. right
(e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or
later)?  If yes, from which versions?  Shall it be based on just target
tripplets for Solaris?

> On Solaris 11/SPARC, the test fails even with gas and gld 2.22:
> 
> > objdump -s -j .init_array conftest
> 
> conftest:     file format elf32-sparc-sol2
> 
> Contents of section .init_array:
>  20054 48484848 44444444                    HHHHDDDD      

If it contains just two, then possibly the .ctors section has been kept around?
I'd guess that H.J's testcase wouldn't succeed either.

Anyway, marking this as fixed, details can be fixed up incrementally.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-19 16:27:44 UTC ---
> --- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:17:29 UTC ---
> (In reply to comment #38)
>> So far, ld -e 0 doesn't work:
>
> Well, if no Sun ld handles the section mixing right, it doesn't matter that

I've been in touch with the linker engineers about this issue, and they
are not convinced that this section merging is mandated by the ELF spec.

> much.  We could just:
>   .text
>   .globl _start
> _start:
> at the end of the assembly otherwise.

True.

>> (Recent?) Sun as on Solaris 10 and 11/x86 work, too.
>
> It will still not default to --enable-initfini-array there, because of the
> glibc version check.  Does Solaris dynamic linker handle .init_array etc. right

I know.

> (e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or
> later)?  If yes, from which versions?  Shall it be based on just target
> tripplets for Solaris?

I'm about to change the glibc check for Solaris.  I'm pretty sure it
works right on Solaris 11, and probably also on (patched) versions of
Solaris 8 and up.  If this is something that has been introduced after
FCS, I'll perform the same ld version checking I did in other cases,
since ld and ld.so.1 are guaranteed to be upgraded in lockstep.

>> On Solaris 11/SPARC, the test fails even with gas and gld 2.22:
>> 
>> > objdump -s -j .init_array conftest
>> 
>> conftest:     file format elf32-sparc-sol2
>> 
>> Contents of section .init_array:
>>  20054 48484848 44444444                    HHHHDDDD      
>
> If it contains just two, then possibly the .ctors section has been kept around?
> I'd guess that H.J's testcase wouldn't succeed either.

Right, it aborts.

> Anyway, marking this as fixed, details can be fixed up incrementally.

Agreed, bootstrapping again out of the box is the primary issue of this PR.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:32:08 UTC ---
It isn't mandated by the ELF spec, but if the linker doesn't do that and either
keeps .ctors and .init_array etc. separate, or merges them but without ensuring
the right order, ctor/dtor priorities won't work correctly.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-19 16:36:56 UTC ---
> --- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:32:08 UTC ---
> It isn't mandated by the ELF spec, but if the linker doesn't do that and either
> keeps .ctors and .init_array etc. separate, or merges them but without ensuring
> the right order, ctor/dtor priorities won't work correctly.

I know.  The question is if adding this gld extension to Sun ld could be
justified and if there's a spec the Oracle guys could use without
reading the gld code.  Especially in Solaris 11, many gld command line
options and features have been added this name to improve compatibility.

IIRC, there are other cases where gld merges sections when Sun ld does
not.

    Rainer

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #43 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-19 23:37:52 UTC ---
(In reply to comment #37)
> Rainer/Andrew, please test this in your configurations.

Yes it works for me now.  Thanks for fixing this issue.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jingyu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #44 from Jing Yu <jingyu at gcc dot gnu.org> 2012-02-22 22:04:45 UTC ---
Author: jingyu
Date: Wed Feb 22 22:04:39 2012
New Revision: 184493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184493
Log:
2012-02-21   Jing Yu  <jingyu@google.com>

    Google Ref 47894
    Backport from mainline r177933, r175181, r177963, r178116, r183299.

    2011-08-20  H.J. Lu  <hongjiu.lu@intel.com>
    PR other/46770
    * config.gcc (tm_file): Add initfini-array.h if
    .init_arrary/.fini_array are supported.
    * crtstuff.c: Don't generate .ctors nor .dtors sections if
    USE_INITFINI_ARRAY is defined.
    * output.h (default_elf_init_array_asm_out_constructor): New.
    (default_elf_fini_array_asm_out_destructor): Likewise.
    * varasm.c (elf_init_array_section): Likewise.
    (elf_fini_array_section): Likewise.
    (get_elf_initfini_array_priority_section): Likewise.
    (default_elf_init_array_asm_out_constructor): Likewise.
    (default_elf_fini_array_asm_out_destructor): Likewise.
    * config/initfini-array.h: New.

    2011-06-18  H.J. Lu  <hongjiu.lu@intel.com>
    PR other/49325
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
    .init_array can be used with .ctors on targets.
    * configure: Regenerated.

    2011-08-22  H.J. Lu  <hongjiu.lu@intel.com>
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't
    defined.
    * configure: Regenerated.

    2011-08-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
    PR target/50166
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main.
    * configure: Regenerate.

    2012-01-19  Jakub Jelinek  <jakub@redhat.com>
    PR bootstrap/50237
    * config/initfini-array.h: Guard content of the header
    with #ifdef HAVE_INITFINI_ARRAY.
    * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the
    file.
    Add initfini-array.h to tm_file here.
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a
    linker test.
    * config.gcc: Don't add initfini-array.h to tm_file here.
    * configure: Regenerated.


Added:
    branches/google/gcc-4_6/gcc/config/initfini-array.h
Modified:
    branches/google/gcc-4_6/gcc/ChangeLog.google-4_6
    branches/google/gcc-4_6/gcc/acinclude.m4
    branches/google/gcc-4_6/gcc/configure
    branches/google/gcc-4_6/gcc/configure.ac
    branches/google/gcc-4_6/gcc/crtstuff.c
    branches/google/gcc-4_6/gcc/output.h
    branches/google/gcc-4_6/gcc/varasm.c

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[jingyu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237

--- Comment #45 from Jing Yu <jingyu at gcc dot gnu.org> 2012-02-22 22:26:45 UTC ---
Author: jingyu
Date: Wed Feb 22 22:26:40 2012
New Revision: 184494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184494
Log:
2012-02-21   Jing Yu  <jingyu@google.com>

    Bakcport r175181, r177963, r178116, r183299 from mainline.

    2011-06-18  H.J. Lu  <hongjiu.lu@intel.com>
    PR other/49325
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
    .init_array can be used with .ctors on targets.
    * configure: Regenerated.

    2011-08-22  H.J. Lu  <hongjiu.lu@intel.com>
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't
    defined.
    * configure: Regenerated.

    2011-08-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
    PR target/50166
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main.
    * configure: Regenerate.

    2012-01-19  Jakub Jelinek  <jakub@redhat.com>
    PR bootstrap/50237
    * config/initfini-array.h: Guard content of the header
    with #ifdef HAVE_INITFINI_ARRAY.
    * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the
    file.
    Add initfini-array.h to tm_file here.
    * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a
    linker test.
    * config.gcc: Don't add initfini-array.h to tm_file here.
    * configure: Regenerated.


Modified:
    branches/google/gcc-4_6_2-mobile/gcc/ChangeLog.google-4_6
    branches/google/gcc-4_6_2-mobile/gcc/acinclude.m4
    branches/google/gcc-4_6_2-mobile/gcc/config.gcc
    branches/google/gcc-4_6_2-mobile/gcc/config/initfini-array.h
    branches/google/gcc-4_6_2-mobile/gcc/configure
    branches/google/gcc-4_6_2-mobile/gcc/configure.ac