On October 27, 2014 1:49:54 AM CET, David Edelsohn <dje....@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 <rguent...@suse.de> >wrote: >> On October 26, 2014 12:26:29 AM CEST, David Edelsohn ><dje....@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....@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....@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....@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 ><rguent...@suse.de> >>>wrote: >>>>>>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn >>><dje....@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 >>>>>>> >>>>>>> >> >>
