Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn <dje dot gcc at gmail dot com>]

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