Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener <richard.guenther@gmail.com>]

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