Without the ipa-inline-analysis.c change, g++ creates a static constructor with global visibility
.globl
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0:
With the patch, g++ creates weak method
.weak ._ZN14__gnu_parallel9_SettingsC1Ev
._ZN14__gnu_parallel9_SettingsC1Ev:
with non-global alias
.lglobl ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0
.set
._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0,._ZN14__gnu_parallel9_SettingsC1Ev
and the static constructor branches to the alias
.globl
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0:
lwz 3,LC..8(2)
b ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0
The code where it's hanging is the AIX "glink" code, essentially a PLT
stub, trying to call the method ._ZN14__gnu_parallel9_SettingsC1Ev
The linker is not seeing the local definition of
._ZN14__gnu_parallel9_SettingsC1Ev. libstdc++ is built with
Linux-like semantics, so it allows symbols to be overridden. AIX calls
everything through the PLT. But the real definition of the function is
not being seen.
I'm not exactly sure why inlining changing this and what these extra
levels of indirections are trying to accomplish. The visibility of the
symbols as declared in the XCOFF assembly files appears to be
preventing the AIX linker and loader from resolving the static
constructor functions.
Thanks David
On Mon, Jun 16, 2014 at 6:06 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> On Mon, Jun 16, 2014 at 12:35 AM, Jan Hubicka <hubi...@ucw.cz> wrote:
>>
>> > @@ -512,9 +516,9 @@ function_and_variable_visibility (bool w
>> > next = next->same_comdat_group)
>> > {
>> > next->set_comdat_group (NULL);
>> > - if (!next->alias)
>> > - next->set_section (NULL);
>> > symtab_make_decl_local (next->decl);
>> > + if (!node->alias)
>> > + node->reset_section ();
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > next->unique_name = ((next->resolution ==
>> > LDPR_PREVAILING_DEF_IRONLY
>> > || next->unique_name
>> > || next->resolution ==
>> > LDPR_PREVAILING_DEF_IRONLY_EXP)
>>
>> Honza, did you really intend to change the above from next->alias and
>> next->set_section () to node->alias and node->reset_section () ? That
>> doesn't look right.
>
> You are right, this is a pasto in anoying code duplication here. I fixed that
> in my local copy of the patch. I have a followup patch in the ipa-visibility
> TLC to merge the code duplication here, I am just holding it until we debug
> the
> issues.
>
> This bug will not affect AIX, becuase there are no comdat groups. It only
> wastes a bit of code size on ELF systems because of extra alignment coming
> from the named section.
>
> The hang happens in
> (gdb) bt
> #0 0x100be244 in __gnu_parallel::_Settings::_Settings() ()
> #1 0x10008d54 in _GLOBAL__FI_libstdc___so ()
> #2 0x10008e88 in _GLOBAL__AIXI_libstdc___so ()
> #3 0x100be954 in _GLOBAL__FI_genconstants ()
> #4 0xd017fa54 in mod_init1 () from /usr/lib/libc.a(shr.o)
> #5 0xd017f774 in __modinit () from /usr/lib/libc.a(shr.o)
> #6 0x100001a0 in __start ()
>
> I suppose it may be crtbegin/crtend miscompile. Any insight would be welcome,
> otherwise I will try to progress on debugging tonight or tomorrow.
>
> Honza
parallel_settings.bad.s
Description: Binary data
parallel_settings.good.s
Description: Binary data
