Hi Honza,
On 23 Jun 2014, at 18:36, Jan Hubicka wrote:
>> The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin
>> with
>>
>> /opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
>> definitions not supported in Mach-O; ignored
>>
>> I think they should b
> The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
>
> /opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
> definitions not supported in Mach-O; ignored
>
> I think they should be protected by
>
> /* { dg-require-alias "" } */
I see, the anoyi
The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
/opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
definitions not supported in Mach-O; ignored
I think they should be protected by
/* { dg-require-alias "" } */
Dominique
> The new testcases also declare main() as "void", but "return 0".
I fixed that with previous commit too (what happened is that I managed to
copy wrong version of the files while testing that they fail on AIX.
They indeed did fail, but for wrong versoin)
Honza
The new testcases also declare main() as "void", but "return 0".
- David
On Fri, Jun 20, 2014 at 10:43 PM, Jan Hubicka wrote:
> Index: testsuite/gcc.dg/localalias.c
> ===
> --- testsuite/gcc.dg/localalias.c (revision 0)
> +++
> > + /* Depending on linker choice, this one may bind locally
> > + or to the other unit. */
> > + if (!testcount && !test2count)
> > +abort();
> > + tt();
> > +
> > + if ((testcount != 1 || test2count != 3)
> > + && (testcount != 3 || test2count != 1))
> > +abort ();
> > +
> Index: testsuite/gcc.dg/localalias.c
> ===
> --- testsuite/gcc.dg/localalias.c (revision 0)
> +++ testsuite/gcc.dg/localalias.c (revision 0)
> @@ -0,0 +1,42 @@
> +/* This test checks that local aliases behave sanely. Thi
Hello,
after some lengthly investigation it turned out that aliases on AIX doesn't
behave in the way we expect. In particular creating a static alias of a global
symbol has no effect. This is somewhat special behaviour of AIX's .set
pseudo-op I think I can get this fixed by simply emitting alterna
On Tue, Jun 17, 2014 at 12:50 PM, Jan Hubicka wrote:
>> > To avoid using PLT and GOT when the unit refers to the symbol and we know
>> > that interposition does not matter.
>>
>> I am not certain if the linker is creating the PLT stub code because
>> it wants to allow interpolation or because it c
> > To avoid using PLT and GOT when the unit refers to the symbol and we know
> > that interposition does not matter.
>
> I am not certain if the linker is creating the PLT stub code because
> it wants to allow interpolation or because it cannot see a definition
> of the function and wants to allo
On Mon, Jun 16, 2014 at 11:44 PM, Jan Hubicka wrote:
>> 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
David,
thanks for the analysis!
> 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_libstd
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
It looks like _Settings is miscompiled, or more specifically a
function descriptor has a bogus value
0x100bcbac <_ZN14__gnu_parallel9_SettingsC1Ev>: addir12,r2,-168
0x100bcbb0 <_ZN14__gnu_parallel9_SettingsC1Ev+4>:stw r2,20(r1)
0x100bcbb4 <_ZN14__gnu_parallel9_SettingsC1E
On Mon, Jun 16, 2014 at 5:44 PM, Jan Hubicka wrote:
> If you don't mind, I would like to commit back the rest of changes
> (reset_section)
> cleanups after testing on AIX + testing the aforementioned ARM testcase.
Please go ahead and commit the parts of the patch that do not cause problems.
Th
> On Mon, Jun 16, 2014 at 12:35 AM, Jan Hubicka wrote:
>
> > @@ -512,9 +516,9 @@ function_and_variable_visibility (bool w
> > next = next->same_comdat_group)
> > {
> > next->set_comdat_group (NULL);
> > - if (!next->alias)
> >
> Honza,
>
> FYI, your bootstrap on gcc111 is hung in the exact same place as I
> have observed: all of the stage2 gen* programs spinning.
Yes (will kill it now), I was tracking down what change it is.
It is actually the inliner hunk that is independent of rest of changes
(and one that should be
On Mon, Jun 16, 2014 at 12:35 AM, Jan Hubicka wrote:
> @@ -512,9 +516,9 @@ function_and_variable_visibility (bool w
> next = next->same_comdat_group)
> {
> next->set_comdat_group (NULL);
> - if (!next->alias)
> -
Honza,
FYI, your bootstrap on gcc111 is hung in the exact same place as I
have observed: all of the stage2 gen* programs spinning.
- David
On Mon, Jun 16, 2014 at 11:08 AM, Jan Hubicka wrote:
>> Honza,
>>
>> Thanks for reverting the patch. I will check if this resolves the
>> current bootstrap
On Mon, Jun 16, 2014 at 4:08 PM, Jan Hubicka wrote:
>> Honza,
>>
>> Thanks for reverting the patch. I will check if this resolves the
>> current bootstrap problem.
>>
>> I was suggesting that you create a branch for all of the visibility
>> changes to make it easier to track the various original p
> Honza,
>
> Thanks for reverting the patch. I will check if this resolves the
> current bootstrap problem.
>
> I was suggesting that you create a branch for all of the visibility
> changes to make it easier to track the various original patches and
> later correction patches from you.
>
> I don
On Mon, Jun 16, 2014 at 5:35 AM, Jan Hubicka wrote:
>> Honza,
>>
>> The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
>> the corresponding patch in the GCC Patches mailing list, so I do not
>> see where this was discussed or approved.
>
> Sorry, I remember writting mail about t
Honza,
Thanks for reverting the patch. I will check if this resolves the
current bootstrap problem.
I was suggesting that you create a branch for all of the visibility
changes to make it easier to track the various original patches and
later correction patches from you.
I don't know if the gen*
> Honza,
>
> The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
> the corresponding patch in the GCC Patches mailing list, so I do not
> see where this was discussed or approved.
Sorry, I remember writting mail about this patch but also can't find it. The
patch introduces rese
Honza,
The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
the corresponding patch in the GCC Patches mailing list, so I do not
see where this was discussed or approved.
With the patch in r211600, the "gen*" programs in stage2 go into an
endless loop.
Please revert these comdat
25 matches
Mail list logo
