On Thu, 30 Oct 2014, David Edelsohn wrote: > On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener > <richard.guent...@gmail.com> wrote: > > On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje....@gmail.com> wrote: > >> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener > >> <richard.guent...@gmail.com> wrote: > >> > >>> Because only genmatch calls functions from libstdc++. Btw, why > >>> would genmatch miscompile an empty function or the call to it? > >> > >> I tried bootstrapping with libstdc++ built without the AIX ld "-G" > >> flag and that is succeeding. > >> > >> "-G" produces a shared object for use with SVR4-style runtime linking, > >> so this version of libstdc++ no longer allows runtime function > >> interposition, e.g., operator new, although it is not used frequently. > >> Something about the GCC-produced tail calls is interacting badly with > >> that feature. > >> > >> Note that this makes GCC bootstrap on AIX very fragile at the moment > >> because it depends on how libstdc++ was built in previous releases. I > >> can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor > >> 4.9.0. A problematic libstdc++ from earlier releases causes genmatch > >> to loop in stage 1. > > > > I see. A bootstrap with IPA ICF disabled did not succeed but runs into > > the same issue in stage2. So I wonder if the issue is latent for much > > longer and genmatch just exposes it now. > > > > I'll see if I can remove the use of std::map from genmatch as a > > workaround. > > I assume that this is a pervasive issue in the interaction between GCC > optimizations and AIX -G linker option. Something expects the second > call to point to a different implementation. I don't know if the > address in the TOC (GOT) is wrong or something expects the second call > to use a different TOC, but there is a circular reference. > > I am going to apply a patch to GCC to not build libstdc++ with -G. I > also will apply it to GCC 4.9 branch. I was hoping that it could be > included in GCC 4.9.2, but I needed to test it thoroughly and Jakub > beat me with the release.
As it might only affect static linking(?) it might be a good idea to run the libstdc++ testsuite with statically linking libstdc++ (-static-libstdc++) before/after such change? That is, make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=unix/-static-libstdc++" (hopefully that is able to add to link flags and not compile-flags only) Thanks, Richard.