This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: genmatch infinite loop during bootstrap on AIX
- From: Richard Biener <rguenther at suse dot de>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 26 Oct 2014 10:36:19 +0100
- Subject: Re: genmatch infinite loop during bootstrap on AIX
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnykRi9tjw4VPpArRaDYYMZvwxjvYt_oqDGMhjmataTLKJA at mail dot gmail dot com> <A9E6708C-0B2E-4925-A30C-62D88990DBC6 at suse dot de> <CAGWvny=ghm7XKQ6y8oMhQDG1Ru=Si8wqorr6nHrAirp02P6pag at mail dot gmail dot com> <CAGWvnym9p7tmE7s2efNW5YjxSDT-vrW-8xJmYzPpRqRodiFGPg at mail dot gmail dot com> <CAGWvnynWYR5FYctJTa2GGvwGo3asvkU23Y-7Om8pLqCT3w-52A at mail dot gmail dot com> <CAGWvny=Zt44No1-nBWcW+J9_tDSXgFj+-DWAz8NyyzF6kXj-RQ at mail dot gmail dot com>
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
>>>>>
>>>>>