This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: genmatch infinite loop during bootstrap on AIX


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]