HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
independent of compiler.  Which GCC does OpenSuSE 11.0 have?

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

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

Only stage2/3 binutils need to be the same and those are relevant for
feature tests.

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

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

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.

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?

In the meantime, you can use --enable-initfini-array/--disable-initfini-array
to work around this.

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?

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

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

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

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.

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

The --disable-initfini-array workaround works fine so downgrading slightly.

A patch is posted at

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

The updated patch is posted at

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

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

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

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

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

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

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

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

> 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

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

> 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

Created attachment 25937 [details]
gcc47-pr50237.patch

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

> 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

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

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

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.

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.

Created attachment 26352 [details]
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?

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

Rainer/Andrew, please test this in your configurations.

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

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

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

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.

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

(In reply to comment #37)
> Rainer/Andrew, please test this in your configurations.

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

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

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