genmatch infinite loop during bootstrap on AIX

genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
to the process:

#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string ()
#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8, op=0x0)
    at /home/dje/src/src/gcc/genmatch.c:2607
#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
    at /home/dje/src/src/gcc/genmatch.c:2669
#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
    at /home/dje/src/src/gcc/genmatch.c:2728
#4  0x1000efc4 in
_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
(this=0x2ff20208, match_location=4614, simplifiers=...,
    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
    at /home/dje/src/src/gcc/genmatch.c:3052
#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
    at /home/dje/src/src/gcc/genmatch.c:2991
#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
    at /home/dje/src/src/gcc/genmatch.c:3090
#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208, r_=0x3003bbec)
    at /home/dje/src/src/gcc/genmatch.c:3122
#9  0x10004acc in main (argc=<error reading variable>,
    argv=<error reading variable>) at  _start_ :3204

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On October 25, 2014 1:33:39 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>to the process:
>
>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>std::allocator<char> >::basic_string ()
>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
>op=0x0)
>    at /home/dje/src/src/gcc/genmatch.c:2607

Does it really hang in libstdc++ or does it loop somewhere in genmatch? Is this stage1 or later?

Does this happen only after the 2nd part of the merge went in? That is, what revision?

Thanks,
Richard.

>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>    at /home/dje/src/src/gcc/genmatch.c:2669
>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>    at /home/dje/src/src/gcc/genmatch.c:2728
>#4  0x1000efc4 in
>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>(this=0x2ff20208, match_location=4614, simplifiers=...,
>    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>    at /home/dje/src/src/gcc/genmatch.c:3052
>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>    at /home/dje/src/src/gcc/genmatch.c:2991
>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>    at /home/dje/src/src/gcc/genmatch.c:3090
>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>r_=0x3003bbec)
>    at /home/dje/src/src/gcc/genmatch.c:3122
>#9  0x10004acc in main (argc=<error reading variable>,
>    argv=<error reading variable>) at  _start_ :3204

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

This occurs in genmatch builti in stage2.  Revision 216674.

Because of the previous build breakage during the merge, it is
difficult to know exactly what was working.  GCC seemed to be able to
build with the earlier genmatch patch.

Running genmatch --gimple match.pd produces no output and spins in libstdc++.

Thanks, David

On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de> wrote:
> On October 25, 2014 1:33:39 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>>to the process:
>>
>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>std::allocator<char> >::basic_string ()
>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
>>op=0x0)
>>    at /home/dje/src/src/gcc/genmatch.c:2607
>
> Does it really hang in libstdc++ or does it loop somewhere in genmatch? Is this stage1 or later?
>
> Does this happen only after the 2nd part of the merge went in? That is, what revision?
>
> Thanks,
> Richard.
>
>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>#4  0x1000efc4 in
>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>r_=0x3003bbec)
>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>#9  0x10004acc in main (argc=<error reading variable>,
>>    argv=<error reading variable>) at  _start_ :3204
>
>

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

It may be fallout from Maxim's scheduler patch.  I'm testing that.
Backing up before Maxim's patch and your genmatch patch does not enter
an endless loop.

- David

On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de> wrote:
> On October 25, 2014 1:33:39 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>>to the process:
>>
>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>std::allocator<char> >::basic_string ()
>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
>>op=0x0)
>>    at /home/dje/src/src/gcc/genmatch.c:2607
>
> Does it really hang in libstdc++ or does it loop somewhere in genmatch? Is this stage1 or later?
>
> Does this happen only after the 2nd part of the merge went in? That is, what revision?
>
> Thanks,
> Richard.
>
>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>#4  0x1000efc4 in
>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>r_=0x3003bbec)
>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>#9  0x10004acc in main (argc=<error reading variable>,
>>    argv=<error reading variable>) at  _start_ :3204
>
>

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

Bootstrap succeeds with Maxim's patch (r216624).

The other, significant changes I see on trunk between r216624 and r216674 are:

match-and-simplify through r216632
ipc-icf in r216662
libstdc++ in r216667

No other patches to trunk *seem* like they should affect PPC bootstrap.

- David


On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> It may be fallout from Maxim's scheduler patch.  I'm testing that.
> Backing up before Maxim's patch and your genmatch patch does not enter
> an endless loop.
>
> - David
>
> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de> wrote:
>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>>>to the process:
>>>
>>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>>std::allocator<char> >::basic_string ()
>>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
>>>op=0x0)
>>>    at /home/dje/src/src/gcc/genmatch.c:2607
>>
>> Does it really hang in libstdc++ or does it loop somewhere in genmatch? Is this stage1 or later?
>>
>> Does this happen only after the 2nd part of the merge went in? That is, what revision?
>>
>> Thanks,
>> Richard.
>>
>>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>>#4  0x1000efc4 in
>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>>    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>>r_=0x3003bbec)
>>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>>#9  0x10004acc in main (argc=<error reading variable>,
>>>    argv=<error reading variable>) at  _start_ :3204
>>
>>

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

Richard,

I confirmed again with gcc111, which fails with r216632 and succeeds
with r216624.

On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
4.8.1, it enters an infinite loop in stage 2.

Thanks, David

On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> Richard,
>
> There definitely seems to be something wrong with genmatch and the
> recent match-and-simplify patch (r216632).  Using a different,
> internal AIX system to speed up testing the potential causes of the
> problem, a tree at r216661 (just before Marxin's patch) hangs in
> genmatch during stage 1 bootstrap using G++ 4.7.3:
>
> (gdb) where
> #0  0x10068158 in std::allocator<char>::allocator() ()
> #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand (this=0x2ff20974, op=0x0)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
> #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
> #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
> #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
> #5  0x1000ba4c in
> _ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
> (this=0x2ff20974, match_location=4614, simplifiers=...,
>     matcher=0x0, result=0x0) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
> #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
> #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
> #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
> #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974, r_=0x3000c8e8)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204
>
> r216624 (after Maxim's sched patches and before your
> match-and-simplify patch) does not have a problem on gcc111.
>
> - David
>
>
> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> Bootstrap succeeds with Maxim's patch (r216624).
>>
>> The other, significant changes I see on trunk between r216624 and r216674 are:
>>
>> match-and-simplify through r216632
>> ipc-icf in r216662
>> libstdc++ in r216667
>>
>> No other patches to trunk *seem* like they should affect PPC bootstrap.
>>
>> - David
>>
>>
>> On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>> It may be fallout from Maxim's scheduler patch.  I'm testing that.
>>> Backing up before Maxim's patch and your genmatch patch does not enter
>>> an endless loop.
>>>
>>> - David
>>>
>>> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de> wrote:
>>>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>>>>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>>>>>to the process:
>>>>>
>>>>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>>>>std::allocator<char> >::basic_string ()
>>>>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
>>>>>op=0x0)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:2607
>>>>
>>>> Does it really hang in libstdc++ or does it loop somewhere in genmatch? Is this stage1 or later?
>>>>
>>>> Does this happen only after the 2nd part of the merge went in? That is, what revision?
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>>>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>>>>#4  0x1000efc4 in
>>>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>>>>    matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>>>>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>>>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>>>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>>>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>>>>r_=0x3003bbec)
>>>>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>>>>#9  0x10004acc in main (argc=<error reading variable>,
>>>>>    argv=<error reading variable>) at  _start_ :3204
>>>>
>>>>

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On October 26, 2014 12:26:29 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>Richard,
>
>I confirmed again with gcc111, which fails with r216632 and succeeds
>with r216624.

Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap before r216632 still fails on AIX?

I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a cfarm account.

Thanks,
Richard.

>On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
>infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
>4.8.1, it enters an infinite loop in stage 2.
>
>Thanks, David
>
>On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn <dje.gcc@gmail.com>
>wrote:
>> Richard,
>>
>> There definitely seems to be something wrong with genmatch and the
>> recent match-and-simplify patch (r216632).  Using a different,
>> internal AIX system to speed up testing the potential causes of the
>> problem, a tree at r216661 (just before Marxin's patch) hangs in
>> genmatch during stage 1 bootstrap using G++ 4.7.3:
>>
>> (gdb) where
>> #0  0x10068158 in std::allocator<char>::allocator() ()
>> #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand
>(this=0x2ff20974, op=0x0)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
>> #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
>> #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
>> #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
>> #5  0x1000ba4c in
>>
>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>> (this=0x2ff20974, match_location=4614, simplifiers=...,
>>     matcher=0x0, result=0x0) at
>/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
>> #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
>> #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
>> #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
>> #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974,
>r_=0x3000c8e8)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
>> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204
>>
>> r216624 (after Maxim's sched patches and before your
>> match-and-simplify patch) does not have a problem on gcc111.
>>
>> - David
>>
>>
>> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn <dje.gcc@gmail.com>
>wrote:
>>> Bootstrap succeeds with Maxim's patch (r216624).
>>>
>>> The other, significant changes I see on trunk between r216624 and
>r216674 are:
>>>
>>> match-and-simplify through r216632
>>> ipc-icf in r216662
>>> libstdc++ in r216667
>>>
>>> No other patches to trunk *seem* like they should affect PPC
>bootstrap.
>>>
>>> - David
>>>
>>>
>>> On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn <dje.gcc@gmail.com>
>wrote:
>>>> It may be fallout from Maxim's scheduler patch.  I'm testing that.
>>>> Backing up before Maxim's patch and your genmatch patch does not
>enter
>>>> an endless loop.
>>>>
>>>> - David
>>>>
>>>> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de>
>wrote:
>>>>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn
><dje.gcc@gmail.com> wrote:
>>>>>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I
>attach
>>>>>>to the process:
>>>>>>
>>>>>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>>>>>std::allocator<char> >::basic_string ()
>>>>>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand
>(this=0x300594b8,
>>>>>>op=0x0)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2607
>>>>>
>>>>> Does it really hang in libstdc++ or does it loop somewhere in
>genmatch? Is this stage1 or later?
>>>>>
>>>>> Does this happen only after the 2nd part of the merge went in?
>That is, what revision?
>>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>>>>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>>>>>#4  0x1000efc4 in
>>>>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>>>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>>>>>    matcher=0x0, result=0x0) at
>/home/dje/src/src/gcc/genmatch.c:2792
>>>>>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>>>>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>>>>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>>>>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>>>>>r_=0x3003bbec)
>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>>>>>#9  0x10004acc in main (argc=<error reading variable>,
>>>>>>    argv=<error reading variable>) at  _start_ :3204
>>>>>
>>>>>

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

Richi,

Does genmatch rely on static constructors or implicitly rely on the
order of static constructors? Sometimes those cause problems on AIX.

Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
after your commit r216619 to correct Makefile.in, or prior to that by
manually editing Makefile.in to add LIBICONV and LIBINTL.

Thanks, David

On Sun, Oct 26, 2014 at 5:36 AM, Richard Biener <rguenther@suse.de> wrote:
> On October 26, 2014 12:26:29 AM CEST, David Edelsohn <dje.gcc@gmail.com> wrote:
>>Richard,
>>
>>I confirmed again with gcc111, which fails with r216632 and succeeds
>>with r216624.
>
> Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap before r216632 still fails on AIX?
>
> I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a cfarm account.
>
> Thanks,
> Richard.
>
>>On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
>>infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
>>4.8.1, it enters an infinite loop in stage 2.
>>
>>Thanks, David
>>
>>On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn <dje.gcc@gmail.com>
>>wrote:
>>> Richard,
>>>
>>> There definitely seems to be something wrong with genmatch and the
>>> recent match-and-simplify patch (r216632).  Using a different,
>>> internal AIX system to speed up testing the potential causes of the
>>> problem, a tree at r216661 (just before Marxin's patch) hangs in
>>> genmatch during stage 1 bootstrap using G++ 4.7.3:
>>>
>>> (gdb) where
>>> #0  0x10068158 in std::allocator<char>::allocator() ()
>>> #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand
>>(this=0x2ff20974, op=0x0)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
>>> #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
>>> #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
>>> #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
>>> #5  0x1000ba4c in
>>>
>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>> (this=0x2ff20974, match_location=4614, simplifiers=...,
>>>     matcher=0x0, result=0x0) at
>>/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
>>> #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
>>> #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
>>> #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
>>> #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974,
>>r_=0x3000c8e8)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
>>> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204
>>>
>>> r216624 (after Maxim's sched patches and before your
>>> match-and-simplify patch) does not have a problem on gcc111.
>>>
>>> - David
>>>
>>>
>>> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn <dje.gcc@gmail.com>
>>wrote:
>>>> Bootstrap succeeds with Maxim's patch (r216624).
>>>>
>>>> The other, significant changes I see on trunk between r216624 and
>>r216674 are:
>>>>
>>>> match-and-simplify through r216632
>>>> ipc-icf in r216662
>>>> libstdc++ in r216667
>>>>
>>>> No other patches to trunk *seem* like they should affect PPC
>>bootstrap.
>>>>
>>>> - David
>>>>
>>>>
>>>> On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn <dje.gcc@gmail.com>
>>wrote:
>>>>> It may be fallout from Maxim's scheduler patch.  I'm testing that.
>>>>> Backing up before Maxim's patch and your genmatch patch does not
>>enter
>>>>> an endless loop.
>>>>>
>>>>> - David
>>>>>
>>>>> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener <rguenther@suse.de>
>>wrote:
>>>>>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn
>><dje.gcc@gmail.com> wrote:
>>>>>>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I
>>attach
>>>>>>>to the process:
>>>>>>>
>>>>>>>#0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>>>>>>std::allocator<char> >::basic_string ()
>>>>>>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand
>>(this=0x300594b8,
>>>>>>>op=0x0)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2607
>>>>>>
>>>>>> Does it really hang in libstdc++ or does it loop somewhere in
>>genmatch? Is this stage1 or later?
>>>>>>
>>>>>> Does this happen only after the 2nd part of the merge went in?
>>That is, what revision?
>>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>>>
>>>>>>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>>>>>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>>>>>>#4  0x1000efc4 in
>>>>>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>>>>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>>>>>>    matcher=0x0, result=0x0) at
>>/home/dje/src/src/gcc/genmatch.c:2792
>>>>>>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>>>>>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>>>>>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>>>>>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>>>>>>r_=0x3003bbec)
>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>>>>>>#9  0x10004acc in main (argc=<error reading variable>,
>>>>>>>    argv=<error reading variable>) at  _start_ :3204
>>>>>>
>>>>>>
>
>

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On October 27, 2014 1:49:54 AM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>Richi,
>
>Does genmatch rely on static constructors or implicitly rely on the
>order of static constructors? Sometimes those cause problems on AIX.

No, it doesn't.

>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>after your commit r216619 to correct Makefile.in, or prior to that by
>manually editing Makefile.in to add LIBICONV and LIBINTL.

OK, so this would mean that r216631 causes a miscompile for you. Though that does not match up with you seeing this happening during stage1...

Bah.

The place where it is looping is using std::map <std::string, unsigned>.

Does -static-libstdc++ work for you host compilers?

Can you try emptying gcc/match.pd for a non-working rev.?

Thanks,
Richard.

>Thanks, David
>
>On Sun, Oct 26, 2014 at 5:36 AM, Richard Biener <rguenther@suse.de>
>wrote:
>> On October 26, 2014 12:26:29 AM CEST, David Edelsohn
><dje.gcc@gmail.com> wrote:
>>>Richard,
>>>
>>>I confirmed again with gcc111, which fails with r216632 and succeeds
>>>with r216624.
>>
>> Can you revert r216631 but still keep the r216632 fix? I suppose
>bootstrap before r216632 still fails on AIX?
>>
>> I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get
>myself a cfarm account.
>>
>> Thanks,
>> Richard.
>>
>>>On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
>>>infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
>>>4.8.1, it enters an infinite loop in stage 2.
>>>
>>>Thanks, David
>>>
>>>On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn <dje.gcc@gmail.com>
>>>wrote:
>>>> Richard,
>>>>
>>>> There definitely seems to be something wrong with genmatch and the
>>>> recent match-and-simplify patch (r216632).  Using a different,
>>>> internal AIX system to speed up testing the potential causes of the
>>>> problem, a tree at r216661 (just before Marxin's patch) hangs in
>>>> genmatch during stage 1 bootstrap using G++ 4.7.3:
>>>>
>>>> (gdb) where
>>>> #0  0x10068158 in std::allocator<char>::allocator() ()
>>>> #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand
>>>(this=0x2ff20974, op=0x0)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
>>>> #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
>>>> #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
>>>> #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
>>>> #5  0x1000ba4c in
>>>>
>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>> (this=0x2ff20974, match_location=4614, simplifiers=...,
>>>>     matcher=0x0, result=0x0) at
>>>/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
>>>> #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
>>>> #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
>>>> #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
>>>> #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974,
>>>r_=0x3000c8e8)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
>>>> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
>>>>     at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204
>>>>
>>>> r216624 (after Maxim's sched patches and before your
>>>> match-and-simplify patch) does not have a problem on gcc111.
>>>>
>>>> - David
>>>>
>>>>
>>>> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn <dje.gcc@gmail.com>
>>>wrote:
>>>>> Bootstrap succeeds with Maxim's patch (r216624).
>>>>>
>>>>> The other, significant changes I see on trunk between r216624 and
>>>r216674 are:
>>>>>
>>>>> match-and-simplify through r216632
>>>>> ipc-icf in r216662
>>>>> libstdc++ in r216667
>>>>>
>>>>> No other patches to trunk *seem* like they should affect PPC
>>>bootstrap.
>>>>>
>>>>> - David
>>>>>
>>>>>
>>>>> On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn
><dje.gcc@gmail.com>
>>>wrote:
>>>>>> It may be fallout from Maxim's scheduler patch.  I'm testing
>that.
>>>>>> Backing up before Maxim's patch and your genmatch patch does not
>>>enter
>>>>>> an endless loop.
>>>>>>
>>>>>> - David
>>>>>>
>>>>>> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener
><rguenther@suse.de>
>>>wrote:
>>>>>>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn
>>><dje.gcc@gmail.com> wrote:
>>>>>>>>genmatch is hanging when bootstrapping on AIX (gcc111).  When I
>>>attach
>>>>>>>>to the process:
>>>>>>>>
>>>>>>>>#0  0x1007efac in std::basic_string<char,
>std::char_traits<char>,
>>>>>>>>std::allocator<char> >::basic_string ()
>>>>>>>>#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand
>>>(this=0x300594b8,
>>>>>>>>op=0x0)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2607
>>>>>>>
>>>>>>> Does it really hang in libstdc++ or does it loop somewhere in
>>>genmatch? Is this stage1 or later?
>>>>>>>
>>>>>>> Does this happen only after the 2nd part of the merge went in?
>>>That is, what revision?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Richard.
>>>>>>>
>>>>>>>>#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2669
>>>>>>>>#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2728
>>>>>>>>#4  0x1000efc4 in
>>>>>>>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>>>>>>>(this=0x2ff20208, match_location=4614, simplifiers=...,
>>>>>>>>    matcher=0x0, result=0x0) at
>>>/home/dje/src/src/gcc/genmatch.c:2792
>>>>>>>>#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3052
>>>>>>>>#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:2991
>>>>>>>>#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3090
>>>>>>>>#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
>>>>>>>>r_=0x3003bbec)
>>>>>>>>    at /home/dje/src/src/gcc/genmatch.c:3122
>>>>>>>>#9  0x10004acc in main (argc=<error reading variable>,
>>>>>>>>    argv=<error reading variable>) at  _start_ :3204
>>>>>>>
>>>>>>>
>>
>>

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On October 27, 2014 1:49:54 AM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>>Richi,
>>
>>Does genmatch rely on static constructors or implicitly rely on the
>>order of static constructors? Sometimes those cause problems on AIX.
>
> No, it doesn't.
>
>>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>>after your commit r216619 to correct Makefile.in, or prior to that by
>>manually editing Makefile.in to add LIBICONV and LIBINTL.
>
> OK, so this would mean that r216631 causes a miscompile for you. Though that does not match up with you seeing this happening during stage1...

gcc111 uses GCC 4.8.1 as the default version of GCC.  That bootstrap
fails in stage 2.

My internal system has GCC 4.7.3 installed.  That bootstrap fails in stage 1.

>
> Bah.
>
> The place where it is looping is using std::map <std::string, unsigned>.

I hope that this isn't a signed char issue.

> Does -static-libstdc++ work for you host compilers?

Yes, GCC uses -static-libstdc++ on AIX.

> Can you try emptying gcc/match.pd for a non-working rev.?

An empty match.pd seems to work.  I will try adding back stanzas and
see where it hangs.

Thanks, David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On October 27, 2014 1:49:54 AM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>>Richi,
>>
>>Does genmatch rely on static constructors or implicitly rely on the
>>order of static constructors? Sometimes those cause problems on AIX.
>
> No, it doesn't.
>
>>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>>after your commit r216619 to correct Makefile.in, or prior to that by
>>manually editing Makefile.in to add LIBICONV and LIBINTL.
>
> OK, so this would mean that r216631 causes a miscompile for you. Though that does not match up with you seeing this happening during stage1...
>
> Bah.
>
> The place where it is looping is using std::map <std::string, unsigned>.
>
> Does -static-libstdc++ work for you host compilers?
>
> Can you try emptying gcc/match.pd for a non-working rev.?

Empty file: success.

Header comment: success.

define_predicates stanza: success.

Any "simplify" stanza (with or without "for" loop): HANG.

- David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On October 27, 2014 1:49:54 AM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>>Richi,
>>
>>Does genmatch rely on static constructors or implicitly rely on the
>>order of static constructors? Sometimes those cause problems on AIX.
>
> No, it doesn't.
>
>>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>>after your commit r216619 to correct Makefile.in, or prior to that by
>>manually editing Makefile.in to add LIBICONV and LIBINTL.
>
> OK, so this would mean that r216631 causes a miscompile for you. Though that does not match up with you seeing this happening during stage1...
>
> Bah.
>
> The place where it is looping is using std::map <std::string, unsigned>.
>
> Does -static-libstdc++ work for you host compilers?
>
> Can you try emptying gcc/match.pd for a non-working rev.?

I am trying a bootstrap with an empty match.pd as a short-term
work-around to allow me to continue bootstrapping and testing GCC
trunk on AIX while we debug this.

- David

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On October 27, 2014 8:13:09 PM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
><richard.guenther@gmail.com> wrote:
>> On October 27, 2014 1:49:54 AM CET, David Edelsohn
><dje.gcc@gmail.com> wrote:
>>>Richi,
>>>
>>>Does genmatch rely on static constructors or implicitly rely on the
>>>order of static constructors? Sometimes those cause problems on AIX.
>>
>> No, it doesn't.
>>
>>>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>>>after your commit r216619 to correct Makefile.in, or prior to that by
>>>manually editing Makefile.in to add LIBICONV and LIBINTL.
>>
>> OK, so this would mean that r216631 causes a miscompile for you.
>Though that does not match up with you seeing this happening during
>stage1...
>>
>> Bah.
>>
>> The place where it is looping is using std::map <std::string,
>unsigned>.
>>
>> Does -static-libstdc++ work for you host compilers?
>>
>> Can you try emptying gcc/match.pd for a non-working rev.?
>
>I am trying a bootstrap with an empty match.pd as a short-term
>work-around to allow me to continue bootstrapping and testing GCC
>trunk on AIX while we debug this.

Not sure if you will be very successful with this :/  I've requested access to the compile-farm so I cab reproduce it. The ppc-linux bootstrap went fine for me.

The stage1 issue must be either host-compiler related or a build machinery issue. I suspect the stage2 issue to be a miscompile of the stage1 libstdc++ or of stage2 genmatch.

Richard.

>- David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

Richi,

The bootstrap with an empty match.pd seems to be succeeding.  I don't
know if you have disabled optimizations in other passes that now are
implemented in genmatch.  Regular testing of AIX is important to
discover bootstrap issues early and avoid more release blocking
issues.

AIX and PPC64 Linux (Big Endian) use basically the same ABI, but PPC64
Linux defaults to 64 bit and AIX defaults to 32 bit, so it's not
testing exactly the same code paths.

Thanks, David


On Mon, Oct 27, 2014 at 4:09 PM, Richard Biener <rguenther@suse.de> wrote:
> On October 27, 2014 8:13:09 PM CET, David Edelsohn <dje.gcc@gmail.com> wrote:
>>On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
>><richard.guenther@gmail.com> wrote:
>>> On October 27, 2014 1:49:54 AM CET, David Edelsohn
>><dje.gcc@gmail.com> wrote:
>>>>Richi,
>>>>
>>>>Does genmatch rely on static constructors or implicitly rely on the
>>>>order of static constructors? Sometimes those cause problems on AIX.
>>>
>>> No, it doesn't.
>>>
>>>>Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
>>>>after your commit r216619 to correct Makefile.in, or prior to that by
>>>>manually editing Makefile.in to add LIBICONV and LIBINTL.
>>>
>>> OK, so this would mean that r216631 causes a miscompile for you.
>>Though that does not match up with you seeing this happening during
>>stage1...
>>>
>>> Bah.
>>>
>>> The place where it is looping is using std::map <std::string,
>>unsigned>.
>>>
>>> Does -static-libstdc++ work for you host compilers?
>>>
>>> Can you try emptying gcc/match.pd for a non-working rev.?
>>
>>I am trying a bootstrap with an empty match.pd as a short-term
>>work-around to allow me to continue bootstrapping and testing GCC
>>trunk on AIX while we debug this.
>
> Not sure if you will be very successful with this :/  I've requested access to the compile-farm so I cab reproduce it. The ppc-linux bootstrap went fine for me.
>
> The stage1 issue must be either host-compiler related or a build machinery issue. I suspect the stage2 issue to be a miscompile of the stage1 libstdc++ or of stage2 genmatch.
>
> Richard.
>
>>- David
>
>

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Mon, 27 Oct 2014, David Edelsohn wrote:

> Richi,
> 
> The bootstrap with an empty match.pd seems to be succeeding.  I don't
> know if you have disabled optimizations in other passes that now are
> implemented in genmatch.  Regular testing of AIX is important to
> discover bootstrap issues early and avoid more release blocking
> issues.

Yes, the patterns implemented in match.pd have been removed from
fold-const.c.  So this will definitely affect some testcases
with respect to constant expressions no longer being constant
for example.

I didn't even expect that bootstrap succeeds - that it does is
good news.

> AIX and PPC64 Linux (Big Endian) use basically the same ABI, but PPC64
> Linux defaults to 64 bit and AIX defaults to 32 bit, so it's not
> testing exactly the same code paths.

Ah, I'm trying --with-cpu=default32 then while waiting for cfarm
access.

Thanks,
Richard.

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Fri, 24 Oct 2014, David Edelsohn wrote:

> genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
> to the process:
> 
> #0  0x1007efac in std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string ()
> #1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8, op=0x0)
>     at /home/dje/src/src/gcc/genmatch.c:2607
> #2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>     at /home/dje/src/src/gcc/genmatch.c:2669
> #3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>     at /home/dje/src/src/gcc/genmatch.c:2728
> #4  0x1000efc4 in
> _ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
> (this=0x2ff20208, match_location=4614, simplifiers=...,
>     matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
> #5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>     at /home/dje/src/src/gcc/genmatch.c:3052
> #6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>     at /home/dje/src/src/gcc/genmatch.c:2991
> #7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>     at /home/dje/src/src/gcc/genmatch.c:3090
> #8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208, r_=0x3003bbec)
>     at /home/dje/src/src/gcc/genmatch.c:3122
> #9  0x10004acc in main (argc=<error reading variable>,
>     argv=<error reading variable>) at  _start_ :3204

(I've re-built stage2 build/genmatch with -g, thus no optimization
and debug info)

Then I see a different frame #0 (std::allocator<char>::allocator()) and
for frame #1 I see

   0x100098b4 <+160>:   stw     r9,88(r31)
   0x100098b8 <+164>:   lwz     r9,152(r31)
   0x100098bc <+168>:   lwz     r30,12(r9)
   0x100098c0 <+172>:   addi    r9,r31,64
   0x100098c4 <+176>:   mr      r3,r9
   0x100098c8 <+180>:   bl      0x100984dc <_ZNSaIcEC1Ev>
=> 0x100098cc <+184>:   lwz     r2,20(r1)

while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information
(maybe I'm missing some tricks for that) even though stage1 libstdc++
was built with -g.  The dissassembly of this (empty!) constructor
looks completely weird though:

(gdb) down
#0  0x100984dc in std::allocator<char>::allocator() ()
(gdb) disassemble
Dump of assembler code for function _ZNSaIcEC1Ev:
=> 0x100984dc <+0>:     addi    r12,r2,-9528
   0x100984e0 <+4>:     stw     r2,20(r1)
   0x100984e4 <+8>:     lwz     r0,0(r12)
   0x100984e8 <+12>:    lwz     r2,4(r12)
   0x100984ec <+16>:    mtctr   r0
   0x100984f0 <+20>:    bctr
   0x100984f4 <+24>:    .long 0x0
   0x100984f8 <+28>:    .long 0xca000
   0x100984fc <+32>:    .long 0x0
   0x10098500 <+36>:    .long 0x18
End of assembler dump.

'bctr' seems to be a jump to $r0 (0x100984dc) here and all other
instructions are fancy no-ops?  I do see a long list of warnings
at link time similar to

ld: 0711-768 WARNING: Object 
/home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst
dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function 
.std::time_ge
t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > 
>::_M_e
xtract_via_format(std::istreambuf_iterator<wchar_t, 
std::char_traits<wchar_t> >,
 std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, 
std::ios_base&,
std::_Ios_Iostate&, tm*, wchar_t const*) const:
        The branch at address 0x10042638 is not followed by a recognized 
no-op
        or TOC-reload instruction. The unrecognized instruction is 
0x4BFFFEBC.

so maybe some weird PPC stuff is not set up correctly in libstdc++
so that the above function doesn't compute its return address
correctly.

Maybe we only run into this because genmatch is the first and only
generator program that actually uses libstdc++ and we don't do
well using a libstdc++ built with -g only (and no optimization).
This is after all the very first entry into libstdc++ (to an
empty function).

I am making the bootstrap continue by copying over stage1 genmatch.
Let's see if stage3 fails the same way (it should use the optimized
libstdc++ from stage2).

Thanks,
Richard.

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener <rguenther@suse.de> wrote:
> On Fri, 24 Oct 2014, David Edelsohn wrote:
>
>> genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>> to the process:
>>
>> #0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >::basic_string ()
>> #1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8, op=0x0)
>>     at /home/dje/src/src/gcc/genmatch.c:2607
>> #2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>     at /home/dje/src/src/gcc/genmatch.c:2669
>> #3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>     at /home/dje/src/src/gcc/genmatch.c:2728
>> #4  0x1000efc4 in
>> _ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>> (this=0x2ff20208, match_location=4614, simplifiers=...,
>>     matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>> #5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>     at /home/dje/src/src/gcc/genmatch.c:3052
>> #6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>     at /home/dje/src/src/gcc/genmatch.c:2991
>> #7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>     at /home/dje/src/src/gcc/genmatch.c:3090
>> #8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208, r_=0x3003bbec)
>>     at /home/dje/src/src/gcc/genmatch.c:3122
>> #9  0x10004acc in main (argc=<error reading variable>,
>>     argv=<error reading variable>) at  _start_ :3204
>
> (I've re-built stage2 build/genmatch with -g, thus no optimization
> and debug info)
>
> Then I see a different frame #0 (std::allocator<char>::allocator()) and
> for frame #1 I see
>
>    0x100098b4 <+160>:   stw     r9,88(r31)
>    0x100098b8 <+164>:   lwz     r9,152(r31)
>    0x100098bc <+168>:   lwz     r30,12(r9)
>    0x100098c0 <+172>:   addi    r9,r31,64
>    0x100098c4 <+176>:   mr      r3,r9
>    0x100098c8 <+180>:   bl      0x100984dc <_ZNSaIcEC1Ev>
> => 0x100098cc <+184>:   lwz     r2,20(r1)
>
> while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information
> (maybe I'm missing some tricks for that) even though stage1 libstdc++
> was built with -g.  The dissassembly of this (empty!) constructor
> looks completely weird though:
>
> (gdb) down
> #0  0x100984dc in std::allocator<char>::allocator() ()
> (gdb) disassemble
> Dump of assembler code for function _ZNSaIcEC1Ev:
> => 0x100984dc <+0>:     addi    r12,r2,-9528
>    0x100984e0 <+4>:     stw     r2,20(r1)
>    0x100984e4 <+8>:     lwz     r0,0(r12)
>    0x100984e8 <+12>:    lwz     r2,4(r12)
>    0x100984ec <+16>:    mtctr   r0
>    0x100984f0 <+20>:    bctr
>    0x100984f4 <+24>:    .long 0x0
>    0x100984f8 <+28>:    .long 0xca000
>    0x100984fc <+32>:    .long 0x0
>    0x10098500 <+36>:    .long 0x18
> End of assembler dump.

bctr is the end of the function.  It is an unconditional, indirect
jump, likely a tail call.

The instructions after the bctr are part of the function epilogue on
AIX with information about the function, originally for AIX exception
handling and stack walking, not used by GCC EH.

>
> 'bctr' seems to be a jump to $r0 (0x100984dc) here and all other
> instructions are fancy no-ops?  I do see a long list of warnings
> at link time similar to
>
> ld: 0711-768 WARNING: Object
> /home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst
> dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function
> .std::time_ge
> t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >
>>::_M_e
> xtract_via_format(std::istreambuf_iterator<wchar_t,
> std::char_traits<wchar_t> >,
>  std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >,
> std::ios_base&,
> std::_Ios_Iostate&, tm*, wchar_t const*) const:
>         The branch at address 0x10042638 is not followed by a recognized
> no-op
>         or TOC-reload instruction. The unrecognized instruction is
> 0x4BFFFEBC.
>
> so maybe some weird PPC stuff is not set up correctly in libstdc++
> so that the above function doesn't compute its return address
> correctly.

Those warnings are normal.  GCC is generating a tail call to a global
function that it knows is in the same translation unit
(binds_local_p).  Depending on how one interprets SVR4 ABI, one should
be able to interpose the call, which could call a function external to
the TU. AIX (and PPC64 BE) require a nop instruction after calls to
global functions that can be replaced with an instruction to restore
the TOC (GOT) if the call is determined to reference a function in
another TU at link-edit time.  The instruction is not followed by the
no-op, so the AIX linker complains.  It's basically complaining that
GCC is being too aggressive in optimization -- tail call to global
function in same source file -- but it's not a bug.

> Maybe we only run into this because genmatch is the first and only
> generator program that actually uses libstdc++ and we don't do
> well using a libstdc++ built with -g only (and no optimization).
> This is after all the very first entry into libstdc++ (to an
> empty function).
>
> I am making the bootstrap continue by copying over stage1 genmatch.
> Let's see if stage3 fails the same way (it should use the optimized
> libstdc++ from stage2).

Why would genmatch have problems while cc1 and cc1plus do not?

Thanks, David

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener <rguenther@suse.de> wrote:
>> On Fri, 24 Oct 2014, David Edelsohn wrote:
>>
>>> genmatch is hanging when bootstrapping on AIX (gcc111).  When I attach
>>> to the process:
>>>
>>> #0  0x1007efac in std::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >::basic_string ()
>>> #1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8, op=0x0)
>>>     at /home/dje/src/src/gcc/genmatch.c:2607
>>> #2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
>>>     at /home/dje/src/src/gcc/genmatch.c:2669
>>> #3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
>>>     at /home/dje/src/src/gcc/genmatch.c:2728
>>> #4  0x1000efc4 in
>>> _ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
>>> (this=0x2ff20208, match_location=4614, simplifiers=...,
>>>     matcher=0x0, result=0x0) at /home/dje/src/src/gcc/genmatch.c:2792
>>> #5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>     at /home/dje/src/src/gcc/genmatch.c:3052
>>> #6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
>>>     at /home/dje/src/src/gcc/genmatch.c:2991
>>> #7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
>>>     at /home/dje/src/src/gcc/genmatch.c:3090
>>> #8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208, r_=0x3003bbec)
>>>     at /home/dje/src/src/gcc/genmatch.c:3122
>>> #9  0x10004acc in main (argc=<error reading variable>,
>>>     argv=<error reading variable>) at  _start_ :3204
>>
>> (I've re-built stage2 build/genmatch with -g, thus no optimization
>> and debug info)
>>
>> Then I see a different frame #0 (std::allocator<char>::allocator()) and
>> for frame #1 I see
>>
>>    0x100098b4 <+160>:   stw     r9,88(r31)
>>    0x100098b8 <+164>:   lwz     r9,152(r31)
>>    0x100098bc <+168>:   lwz     r30,12(r9)
>>    0x100098c0 <+172>:   addi    r9,r31,64
>>    0x100098c4 <+176>:   mr      r3,r9
>>    0x100098c8 <+180>:   bl      0x100984dc <_ZNSaIcEC1Ev>
>> => 0x100098cc <+184>:   lwz     r2,20(r1)
>>
>> while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information
>> (maybe I'm missing some tricks for that) even though stage1 libstdc++
>> was built with -g.  The dissassembly of this (empty!) constructor
>> looks completely weird though:
>>
>> (gdb) down
>> #0  0x100984dc in std::allocator<char>::allocator() ()
>> (gdb) disassemble
>> Dump of assembler code for function _ZNSaIcEC1Ev:
>> => 0x100984dc <+0>:     addi    r12,r2,-9528
>>    0x100984e0 <+4>:     stw     r2,20(r1)
>>    0x100984e4 <+8>:     lwz     r0,0(r12)
>>    0x100984e8 <+12>:    lwz     r2,4(r12)
>>    0x100984ec <+16>:    mtctr   r0
>>    0x100984f0 <+20>:    bctr
>>    0x100984f4 <+24>:    .long 0x0
>>    0x100984f8 <+28>:    .long 0xca000
>>    0x100984fc <+32>:    .long 0x0
>>    0x10098500 <+36>:    .long 0x18
>> End of assembler dump.
>
> bctr is the end of the function.  It is an unconditional, indirect
> jump, likely a tail call.
>
> The instructions after the bctr are part of the function epilogue on
> AIX with information about the function, originally for AIX exception
> handling and stack walking, not used by GCC EH.
>
>>
>> 'bctr' seems to be a jump to $r0 (0x100984dc) here and all other
>> instructions are fancy no-ops?  I do see a long list of warnings
>> at link time similar to
>>
>> ld: 0711-768 WARNING: Object
>> /home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst
>> dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function
>> .std::time_ge
>> t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >
>>>::_M_e
>> xtract_via_format(std::istreambuf_iterator<wchar_t,
>> std::char_traits<wchar_t> >,
>>  std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >,
>> std::ios_base&,
>> std::_Ios_Iostate&, tm*, wchar_t const*) const:
>>         The branch at address 0x10042638 is not followed by a recognized
>> no-op
>>         or TOC-reload instruction. The unrecognized instruction is
>> 0x4BFFFEBC.
>>
>> so maybe some weird PPC stuff is not set up correctly in libstdc++
>> so that the above function doesn't compute its return address
>> correctly.
>
> Those warnings are normal.  GCC is generating a tail call to a global
> function that it knows is in the same translation unit
> (binds_local_p).  Depending on how one interprets SVR4 ABI, one should
> be able to interpose the call, which could call a function external to
> the TU. AIX (and PPC64 BE) require a nop instruction after calls to
> global functions that can be replaced with an instruction to restore
> the TOC (GOT) if the call is determined to reference a function in
> another TU at link-edit time.  The instruction is not followed by the
> no-op, so the AIX linker complains.  It's basically complaining that
> GCC is being too aggressive in optimization -- tail call to global
> function in same source file -- but it's not a bug.
>
>> Maybe we only run into this because genmatch is the first and only
>> generator program that actually uses libstdc++ and we don't do
>> well using a libstdc++ built with -g only (and no optimization).
>> This is after all the very first entry into libstdc++ (to an
>> empty function).
>>
>> I am making the bootstrap continue by copying over stage1 genmatch.
>> Let's see if stage3 fails the same way (it should use the optimized
>> libstdc++ from stage2).
>
> Why would genmatch have problems while cc1 and cc1plus do not?

Because only genmatch calls functions from libstdc++.  Btw, why
would genmatch miscompile an empty function or the call to it?

Richard.

> Thanks, David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
<richard.guenther@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.

Thanks, David

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
> <richard.guenther@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.

Thanks,
Richard.

> Thanks, David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
>> <richard.guenther@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.

- David

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Thu, 30 Oct 2014, David Edelsohn wrote:

> On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> >> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
> >> <richard.guenther@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.