From: Richard Biener <richard.guenther@gmail.com>
To: David Edelsohn <dje.gcc@gmail.com>,Richard Biener <rguenther@suse.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: genmatch infinite loop during bootstrap on AIX
Date: Mon, 27 Oct 2014 07:48:00 -0000 [thread overview]
Message-ID: <C3399E76-42FD-47B0-87CA-2F24C36B930F@gmail.com> (raw)
In-Reply-To: <CAGWvny=f9Y=3VQC=RjH7x6xw8Xj9ywyCEWx9ec1u=ikhtOx7hw@mail.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
>>>>>>>
>>>>>>>
>>
>>
next prev parent reply other threads:[~2014-10-27 6:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 23:37 David Edelsohn
2014-10-25 8:08 ` Richard Biener
2014-10-25 14:05 ` David Edelsohn
2014-10-25 15:16 ` David Edelsohn
2014-10-25 17:40 ` David Edelsohn
[not found] ` <CAGWvnynWYR5FYctJTa2GGvwGo3asvkU23Y-7Om8pLqCT3w-52A@mail.gmail.com>
2014-10-26 6:40 ` David Edelsohn
2014-10-26 10:37 ` Richard Biener
2014-10-27 1:36 ` David Edelsohn
2014-10-27 7:48 ` Richard Biener [this message]
2014-10-27 14:32 ` David Edelsohn
2014-10-27 14:56 ` David Edelsohn
2014-10-27 19:28 ` David Edelsohn
2014-10-27 20:13 ` Richard Biener
2014-10-27 23:36 ` David Edelsohn
2014-10-28 8:43 ` Richard Biener
2014-10-29 12:54 ` Richard Biener
2014-10-29 13:23 ` David Edelsohn
2014-10-29 13:31 ` Richard Biener
2014-10-29 17:31 ` David Edelsohn
2014-10-30 8:54 ` Richard Biener
2014-10-30 14:29 ` David Edelsohn
2014-10-31 8:54 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C3399E76-42FD-47B0-87CA-2F24C36B930F@gmail.com \
--to=richard.guenther@gmail.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).