* genmatch infinite loop during bootstrap on AIX @ 2014-10-24 23:37 David Edelsohn 2014-10-25 8:08 ` Richard Biener 2014-10-29 12:54 ` Richard Biener 0 siblings, 2 replies; 22+ messages in thread From: David Edelsohn @ 2014-10-24 23:37 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches 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 #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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-24 23:37 genmatch infinite loop during bootstrap on AIX 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-29 12:54 ` Richard Biener 1 sibling, 2 replies; 22+ messages in thread From: Richard Biener @ 2014-10-25 8:08 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-25 8:08 ` Richard Biener @ 2014-10-25 14:05 ` David Edelsohn 2014-10-25 15:16 ` David Edelsohn 1 sibling, 0 replies; 22+ messages in thread From: David Edelsohn @ 2014-10-25 14:05 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches This occurs in genmatch builti in stage2. Revision 216674. Because of the previous build breakage during the merge, it is difficult to know exactly what was working. GCC seemed to be able to build with the earlier genmatch patch. Running genmatch --gimple match.pd produces no output and spins in libstdc++. Thanks, 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 > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 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 1 sibling, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-25 15:16 UTC (permalink / raw) To: Richard Biener, Maxim Kuvyrkov; +Cc: GCC Patches 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 > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-25 15:16 ` David Edelsohn @ 2014-10-25 17:40 ` David Edelsohn [not found] ` <CAGWvnynWYR5FYctJTa2GGvwGo3asvkU23Y-7Om8pLqCT3w-52A@mail.gmail.com> 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-25 17:40 UTC (permalink / raw) To: Richard Biener, Maxim Kuvyrkov, Martin Liška, Paolo Carlini, Jan Hubicka Cc: GCC Patches 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 >> >> ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <CAGWvnynWYR5FYctJTa2GGvwGo3asvkU23Y-7Om8pLqCT3w-52A@mail.gmail.com>]
* Re: genmatch infinite loop during bootstrap on AIX [not found] ` <CAGWvnynWYR5FYctJTa2GGvwGo3asvkU23Y-7Om8pLqCT3w-52A@mail.gmail.com> @ 2014-10-26 6:40 ` David Edelsohn 2014-10-26 10:37 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-26 6:40 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches Richard, I confirmed again with gcc111, which fails with r216632 and succeeds with r216624. 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 >>>> >>>> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-26 6:40 ` David Edelsohn @ 2014-10-26 10:37 ` Richard Biener 2014-10-27 1:36 ` David Edelsohn 0 siblings, 1 reply; 22+ messages in thread From: Richard Biener @ 2014-10-26 10:37 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC Patches 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 >>>>> >>>>> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-26 10:37 ` Richard Biener @ 2014-10-27 1:36 ` David Edelsohn 2014-10-27 7:48 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-27 1:36 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches 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 >>>>>> >>>>>> > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 1:36 ` David Edelsohn @ 2014-10-27 7:48 ` Richard Biener 2014-10-27 14:32 ` David Edelsohn ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Richard Biener @ 2014-10-27 7:48 UTC (permalink / raw) To: David Edelsohn, Richard Biener; +Cc: GCC Patches 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 >>>>>>> >>>>>>> >> >> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 7:48 ` Richard Biener @ 2014-10-27 14:32 ` David Edelsohn 2014-10-27 14:56 ` David Edelsohn 2014-10-27 19:28 ` David Edelsohn 2 siblings, 0 replies; 22+ messages in thread From: David Edelsohn @ 2014-10-27 14:32 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener <richard.guenther@gmail.com> wrote: > 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... gcc111 uses GCC 4.8.1 as the default version of GCC. That bootstrap fails in stage 2. My internal system has GCC 4.7.3 installed. That bootstrap fails in stage 1. > > Bah. > > The place where it is looping is using std::map <std::string, unsigned>. I hope that this isn't a signed char issue. > Does -static-libstdc++ work for you host compilers? Yes, GCC uses -static-libstdc++ on AIX. > Can you try emptying gcc/match.pd for a non-working rev.? An empty match.pd seems to work. I will try adding back stanzas and see where it hangs. Thanks, David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 7:48 ` Richard Biener 2014-10-27 14:32 ` David Edelsohn @ 2014-10-27 14:56 ` David Edelsohn 2014-10-27 19:28 ` David Edelsohn 2 siblings, 0 replies; 22+ messages in thread From: David Edelsohn @ 2014-10-27 14:56 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener <richard.guenther@gmail.com> wrote: > 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.? Empty file: success. Header comment: success. define_predicates stanza: success. Any "simplify" stanza (with or without "for" loop): HANG. - David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 7:48 ` Richard Biener 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 2 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-27 19:28 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener <richard.guenther@gmail.com> wrote: > 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.? I am trying a bootstrap with an empty match.pd as a short-term work-around to allow me to continue bootstrapping and testing GCC trunk on AIX while we debug this. - David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 19:28 ` David Edelsohn @ 2014-10-27 20:13 ` Richard Biener 2014-10-27 23:36 ` David Edelsohn 0 siblings, 1 reply; 22+ messages in thread From: Richard Biener @ 2014-10-27 20:13 UTC (permalink / raw) To: David Edelsohn, Richard Biener; +Cc: GCC Patches On October 27, 2014 8:13:09 PM CET, David Edelsohn <dje.gcc@gmail.com> wrote: >On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener ><richard.guenther@gmail.com> wrote: >> 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.? > >I am trying a bootstrap with an empty match.pd as a short-term >work-around to allow me to continue bootstrapping and testing GCC >trunk on AIX while we debug this. Not sure if you will be very successful with this :/ I've requested access to the compile-farm so I cab reproduce it. The ppc-linux bootstrap went fine for me. The stage1 issue must be either host-compiler related or a build machinery issue. I suspect the stage2 issue to be a miscompile of the stage1 libstdc++ or of stage2 genmatch. Richard. >- David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 20:13 ` Richard Biener @ 2014-10-27 23:36 ` David Edelsohn 2014-10-28 8:43 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-27 23:36 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches Richi, The bootstrap with an empty match.pd seems to be succeeding. I don't know if you have disabled optimizations in other passes that now are implemented in genmatch. Regular testing of AIX is important to discover bootstrap issues early and avoid more release blocking issues. AIX and PPC64 Linux (Big Endian) use basically the same ABI, but PPC64 Linux defaults to 64 bit and AIX defaults to 32 bit, so it's not testing exactly the same code paths. Thanks, David On Mon, Oct 27, 2014 at 4:09 PM, Richard Biener <rguenther@suse.de> wrote: > On October 27, 2014 8:13:09 PM CET, David Edelsohn <dje.gcc@gmail.com> wrote: >>On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener >><richard.guenther@gmail.com> wrote: >>> 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.? >> >>I am trying a bootstrap with an empty match.pd as a short-term >>work-around to allow me to continue bootstrapping and testing GCC >>trunk on AIX while we debug this. > > Not sure if you will be very successful with this :/ I've requested access to the compile-farm so I cab reproduce it. The ppc-linux bootstrap went fine for me. > > The stage1 issue must be either host-compiler related or a build machinery issue. I suspect the stage2 issue to be a miscompile of the stage1 libstdc++ or of stage2 genmatch. > > Richard. > >>- David > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-27 23:36 ` David Edelsohn @ 2014-10-28 8:43 ` Richard Biener 0 siblings, 0 replies; 22+ messages in thread From: Richard Biener @ 2014-10-28 8:43 UTC (permalink / raw) To: David Edelsohn; +Cc: Richard Biener, GCC Patches On Mon, 27 Oct 2014, David Edelsohn wrote: > Richi, > > The bootstrap with an empty match.pd seems to be succeeding. I don't > know if you have disabled optimizations in other passes that now are > implemented in genmatch. Regular testing of AIX is important to > discover bootstrap issues early and avoid more release blocking > issues. Yes, the patterns implemented in match.pd have been removed from fold-const.c. So this will definitely affect some testcases with respect to constant expressions no longer being constant for example. I didn't even expect that bootstrap succeeds - that it does is good news. > AIX and PPC64 Linux (Big Endian) use basically the same ABI, but PPC64 > Linux defaults to 64 bit and AIX defaults to 32 bit, so it's not > testing exactly the same code paths. Ah, I'm trying --with-cpu=default32 then while waiting for cfarm access. Thanks, Richard. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-24 23:37 genmatch infinite loop during bootstrap on AIX David Edelsohn 2014-10-25 8:08 ` Richard Biener @ 2014-10-29 12:54 ` Richard Biener 2014-10-29 13:23 ` David Edelsohn 1 sibling, 1 reply; 22+ messages in thread From: Richard Biener @ 2014-10-29 12:54 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC Patches On Fri, 24 Oct 2014, David Edelsohn 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 > #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 (I've re-built stage2 build/genmatch with -g, thus no optimization and debug info) Then I see a different frame #0 (std::allocator<char>::allocator()) and for frame #1 I see 0x100098b4 <+160>: stw r9,88(r31) 0x100098b8 <+164>: lwz r9,152(r31) 0x100098bc <+168>: lwz r30,12(r9) 0x100098c0 <+172>: addi r9,r31,64 0x100098c4 <+176>: mr r3,r9 0x100098c8 <+180>: bl 0x100984dc <_ZNSaIcEC1Ev> => 0x100098cc <+184>: lwz r2,20(r1) while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information (maybe I'm missing some tricks for that) even though stage1 libstdc++ was built with -g. The dissassembly of this (empty!) constructor looks completely weird though: (gdb) down #0 0x100984dc in std::allocator<char>::allocator() () (gdb) disassemble Dump of assembler code for function _ZNSaIcEC1Ev: => 0x100984dc <+0>: addi r12,r2,-9528 0x100984e0 <+4>: stw r2,20(r1) 0x100984e4 <+8>: lwz r0,0(r12) 0x100984e8 <+12>: lwz r2,4(r12) 0x100984ec <+16>: mtctr r0 0x100984f0 <+20>: bctr 0x100984f4 <+24>: .long 0x0 0x100984f8 <+28>: .long 0xca000 0x100984fc <+32>: .long 0x0 0x10098500 <+36>: .long 0x18 End of assembler dump. 'bctr' seems to be a jump to $r0 (0x100984dc) here and all other instructions are fancy no-ops? I do see a long list of warnings at link time similar to ld: 0711-768 WARNING: Object /home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function .std::time_ge t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::_M_e xtract_via_format(std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::ios_base&, std::_Ios_Iostate&, tm*, wchar_t const*) const: The branch at address 0x10042638 is not followed by a recognized no-op or TOC-reload instruction. The unrecognized instruction is 0x4BFFFEBC. so maybe some weird PPC stuff is not set up correctly in libstdc++ so that the above function doesn't compute its return address correctly. Maybe we only run into this because genmatch is the first and only generator program that actually uses libstdc++ and we don't do well using a libstdc++ built with -g only (and no optimization). This is after all the very first entry into libstdc++ (to an empty function). I am making the bootstrap continue by copying over stage1 genmatch. Let's see if stage3 fails the same way (it should use the optimized libstdc++ from stage2). Thanks, Richard. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-29 12:54 ` Richard Biener @ 2014-10-29 13:23 ` David Edelsohn 2014-10-29 13:31 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-29 13:23 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener <rguenther@suse.de> wrote: > On Fri, 24 Oct 2014, David Edelsohn 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 >> #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 > > (I've re-built stage2 build/genmatch with -g, thus no optimization > and debug info) > > Then I see a different frame #0 (std::allocator<char>::allocator()) and > for frame #1 I see > > 0x100098b4 <+160>: stw r9,88(r31) > 0x100098b8 <+164>: lwz r9,152(r31) > 0x100098bc <+168>: lwz r30,12(r9) > 0x100098c0 <+172>: addi r9,r31,64 > 0x100098c4 <+176>: mr r3,r9 > 0x100098c8 <+180>: bl 0x100984dc <_ZNSaIcEC1Ev> > => 0x100098cc <+184>: lwz r2,20(r1) > > while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information > (maybe I'm missing some tricks for that) even though stage1 libstdc++ > was built with -g. The dissassembly of this (empty!) constructor > looks completely weird though: > > (gdb) down > #0 0x100984dc in std::allocator<char>::allocator() () > (gdb) disassemble > Dump of assembler code for function _ZNSaIcEC1Ev: > => 0x100984dc <+0>: addi r12,r2,-9528 > 0x100984e0 <+4>: stw r2,20(r1) > 0x100984e4 <+8>: lwz r0,0(r12) > 0x100984e8 <+12>: lwz r2,4(r12) > 0x100984ec <+16>: mtctr r0 > 0x100984f0 <+20>: bctr > 0x100984f4 <+24>: .long 0x0 > 0x100984f8 <+28>: .long 0xca000 > 0x100984fc <+32>: .long 0x0 > 0x10098500 <+36>: .long 0x18 > End of assembler dump. bctr is the end of the function. It is an unconditional, indirect jump, likely a tail call. The instructions after the bctr are part of the function epilogue on AIX with information about the function, originally for AIX exception handling and stack walking, not used by GCC EH. > > 'bctr' seems to be a jump to $r0 (0x100984dc) here and all other > instructions are fancy no-ops? I do see a long list of warnings > at link time similar to > > ld: 0711-768 WARNING: Object > /home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst > dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function > .std::time_ge > t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >>::_M_e > xtract_via_format(std::istreambuf_iterator<wchar_t, > std::char_traits<wchar_t> >, > std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, > std::ios_base&, > std::_Ios_Iostate&, tm*, wchar_t const*) const: > The branch at address 0x10042638 is not followed by a recognized > no-op > or TOC-reload instruction. The unrecognized instruction is > 0x4BFFFEBC. > > so maybe some weird PPC stuff is not set up correctly in libstdc++ > so that the above function doesn't compute its return address > correctly. Those warnings are normal. GCC is generating a tail call to a global function that it knows is in the same translation unit (binds_local_p). Depending on how one interprets SVR4 ABI, one should be able to interpose the call, which could call a function external to the TU. AIX (and PPC64 BE) require a nop instruction after calls to global functions that can be replaced with an instruction to restore the TOC (GOT) if the call is determined to reference a function in another TU at link-edit time. The instruction is not followed by the no-op, so the AIX linker complains. It's basically complaining that GCC is being too aggressive in optimization -- tail call to global function in same source file -- but it's not a bug. > Maybe we only run into this because genmatch is the first and only > generator program that actually uses libstdc++ and we don't do > well using a libstdc++ built with -g only (and no optimization). > This is after all the very first entry into libstdc++ (to an > empty function). > > I am making the bootstrap continue by copying over stage1 genmatch. > Let's see if stage3 fails the same way (it should use the optimized > libstdc++ from stage2). Why would genmatch have problems while cc1 and cc1plus do not? Thanks, David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-29 13:23 ` David Edelsohn @ 2014-10-29 13:31 ` Richard Biener 2014-10-29 17:31 ` David Edelsohn 0 siblings, 1 reply; 22+ messages in thread From: Richard Biener @ 2014-10-29 13:31 UTC (permalink / raw) To: David Edelsohn; +Cc: Richard Biener, GCC Patches On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener <rguenther@suse.de> wrote: >> On Fri, 24 Oct 2014, David Edelsohn 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 >>> #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 >> >> (I've re-built stage2 build/genmatch with -g, thus no optimization >> and debug info) >> >> Then I see a different frame #0 (std::allocator<char>::allocator()) and >> for frame #1 I see >> >> 0x100098b4 <+160>: stw r9,88(r31) >> 0x100098b8 <+164>: lwz r9,152(r31) >> 0x100098bc <+168>: lwz r30,12(r9) >> 0x100098c0 <+172>: addi r9,r31,64 >> 0x100098c4 <+176>: mr r3,r9 >> 0x100098c8 <+180>: bl 0x100984dc <_ZNSaIcEC1Ev> >> => 0x100098cc <+184>: lwz r2,20(r1) >> >> while for _ZNSaIcEC1Ev there doesn't seem to be proper debug information >> (maybe I'm missing some tricks for that) even though stage1 libstdc++ >> was built with -g. The dissassembly of this (empty!) constructor >> looks completely weird though: >> >> (gdb) down >> #0 0x100984dc in std::allocator<char>::allocator() () >> (gdb) disassemble >> Dump of assembler code for function _ZNSaIcEC1Ev: >> => 0x100984dc <+0>: addi r12,r2,-9528 >> 0x100984e0 <+4>: stw r2,20(r1) >> 0x100984e4 <+8>: lwz r0,0(r12) >> 0x100984e8 <+12>: lwz r2,4(r12) >> 0x100984ec <+16>: mtctr r0 >> 0x100984f0 <+20>: bctr >> 0x100984f4 <+24>: .long 0x0 >> 0x100984f8 <+28>: .long 0xca000 >> 0x100984fc <+32>: .long 0x0 >> 0x10098500 <+36>: .long 0x18 >> End of assembler dump. > > bctr is the end of the function. It is an unconditional, indirect > jump, likely a tail call. > > The instructions after the bctr are part of the function epilogue on > AIX with information about the function, originally for AIX exception > handling and stack walking, not used by GCC EH. > >> >> 'bctr' seems to be a jump to $r0 (0x100984dc) here and all other >> instructions are fancy no-ops? I do see a long list of warnings >> at link time similar to >> >> ld: 0711-768 WARNING: Object >> /home/rguenth/obj/prev-powerpc-ibm-aix7.1.0.0/libst >> dc++-v3/src/.libs/libstdc++.a[libstdc++.so.6], section 1, function >> .std::time_ge >> t<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >>>::_M_e >> xtract_via_format(std::istreambuf_iterator<wchar_t, >> std::char_traits<wchar_t> >, >> std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, >> std::ios_base&, >> std::_Ios_Iostate&, tm*, wchar_t const*) const: >> The branch at address 0x10042638 is not followed by a recognized >> no-op >> or TOC-reload instruction. The unrecognized instruction is >> 0x4BFFFEBC. >> >> so maybe some weird PPC stuff is not set up correctly in libstdc++ >> so that the above function doesn't compute its return address >> correctly. > > Those warnings are normal. GCC is generating a tail call to a global > function that it knows is in the same translation unit > (binds_local_p). Depending on how one interprets SVR4 ABI, one should > be able to interpose the call, which could call a function external to > the TU. AIX (and PPC64 BE) require a nop instruction after calls to > global functions that can be replaced with an instruction to restore > the TOC (GOT) if the call is determined to reference a function in > another TU at link-edit time. The instruction is not followed by the > no-op, so the AIX linker complains. It's basically complaining that > GCC is being too aggressive in optimization -- tail call to global > function in same source file -- but it's not a bug. > >> Maybe we only run into this because genmatch is the first and only >> generator program that actually uses libstdc++ and we don't do >> well using a libstdc++ built with -g only (and no optimization). >> This is after all the very first entry into libstdc++ (to an >> empty function). >> >> I am making the bootstrap continue by copying over stage1 genmatch. >> Let's see if stage3 fails the same way (it should use the optimized >> libstdc++ from stage2). > > Why would genmatch have problems while cc1 and cc1plus do not? Because only genmatch calls functions from libstdc++. Btw, why would genmatch miscompile an empty function or the call to it? Richard. > Thanks, David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-29 13:31 ` Richard Biener @ 2014-10-29 17:31 ` David Edelsohn 2014-10-30 8:54 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-29 17:31 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener <richard.guenther@gmail.com> wrote: > Because only genmatch calls functions from libstdc++. Btw, why > would genmatch miscompile an empty function or the call to it? I tried bootstrapping with libstdc++ built without the AIX ld "-G" flag and that is succeeding. "-G" produces a shared object for use with SVR4-style runtime linking, so this version of libstdc++ no longer allows runtime function interposition, e.g., operator new, although it is not used frequently. Something about the GCC-produced tail calls is interacting badly with that feature. Note that this makes GCC bootstrap on AIX very fragile at the moment because it depends on how libstdc++ was built in previous releases. I can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor 4.9.0. A problematic libstdc++ from earlier releases causes genmatch to loop in stage 1. Thanks, David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-29 17:31 ` David Edelsohn @ 2014-10-30 8:54 ` Richard Biener 2014-10-30 14:29 ` David Edelsohn 0 siblings, 1 reply; 22+ messages in thread From: Richard Biener @ 2014-10-30 8:54 UTC (permalink / raw) To: David Edelsohn; +Cc: Richard Biener, GCC Patches On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener > <richard.guenther@gmail.com> wrote: > >> Because only genmatch calls functions from libstdc++. Btw, why >> would genmatch miscompile an empty function or the call to it? > > I tried bootstrapping with libstdc++ built without the AIX ld "-G" > flag and that is succeeding. > > "-G" produces a shared object for use with SVR4-style runtime linking, > so this version of libstdc++ no longer allows runtime function > interposition, e.g., operator new, although it is not used frequently. > Something about the GCC-produced tail calls is interacting badly with > that feature. > > Note that this makes GCC bootstrap on AIX very fragile at the moment > because it depends on how libstdc++ was built in previous releases. I > can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor > 4.9.0. A problematic libstdc++ from earlier releases causes genmatch > to loop in stage 1. I see. A bootstrap with IPA ICF disabled did not succeed but runs into the same issue in stage2. So I wonder if the issue is latent for much longer and genmatch just exposes it now. I'll see if I can remove the use of std::map from genmatch as a workaround. Thanks, Richard. > Thanks, David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-30 8:54 ` Richard Biener @ 2014-10-30 14:29 ` David Edelsohn 2014-10-31 8:54 ` Richard Biener 0 siblings, 1 reply; 22+ messages in thread From: David Edelsohn @ 2014-10-30 14:29 UTC (permalink / raw) To: Richard Biener; +Cc: Richard Biener, GCC Patches On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener <richard.guenther@gmail.com> wrote: > On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener >> <richard.guenther@gmail.com> wrote: >> >>> Because only genmatch calls functions from libstdc++. Btw, why >>> would genmatch miscompile an empty function or the call to it? >> >> I tried bootstrapping with libstdc++ built without the AIX ld "-G" >> flag and that is succeeding. >> >> "-G" produces a shared object for use with SVR4-style runtime linking, >> so this version of libstdc++ no longer allows runtime function >> interposition, e.g., operator new, although it is not used frequently. >> Something about the GCC-produced tail calls is interacting badly with >> that feature. >> >> Note that this makes GCC bootstrap on AIX very fragile at the moment >> because it depends on how libstdc++ was built in previous releases. I >> can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor >> 4.9.0. A problematic libstdc++ from earlier releases causes genmatch >> to loop in stage 1. > > I see. A bootstrap with IPA ICF disabled did not succeed but runs into > the same issue in stage2. So I wonder if the issue is latent for much > longer and genmatch just exposes it now. > > I'll see if I can remove the use of std::map from genmatch as a > workaround. I assume that this is a pervasive issue in the interaction between GCC optimizations and AIX -G linker option. Something expects the second call to point to a different implementation. I don't know if the address in the TOC (GOT) is wrong or something expects the second call to use a different TOC, but there is a circular reference. I am going to apply a patch to GCC to not build libstdc++ with -G. I also will apply it to GCC 4.9 branch. I was hoping that it could be included in GCC 4.9.2, but I needed to test it thoroughly and Jakub beat me with the release. - David ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: genmatch infinite loop during bootstrap on AIX 2014-10-30 14:29 ` David Edelsohn @ 2014-10-31 8:54 ` Richard Biener 0 siblings, 0 replies; 22+ messages in thread From: Richard Biener @ 2014-10-31 8:54 UTC (permalink / raw) To: David Edelsohn; +Cc: Richard Biener, GCC Patches On Thu, 30 Oct 2014, David Edelsohn wrote: > On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener > <richard.guenther@gmail.com> wrote: > > On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: > >> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener > >> <richard.guenther@gmail.com> wrote: > >> > >>> Because only genmatch calls functions from libstdc++. Btw, why > >>> would genmatch miscompile an empty function or the call to it? > >> > >> I tried bootstrapping with libstdc++ built without the AIX ld "-G" > >> flag and that is succeeding. > >> > >> "-G" produces a shared object for use with SVR4-style runtime linking, > >> so this version of libstdc++ no longer allows runtime function > >> interposition, e.g., operator new, although it is not used frequently. > >> Something about the GCC-produced tail calls is interacting badly with > >> that feature. > >> > >> Note that this makes GCC bootstrap on AIX very fragile at the moment > >> because it depends on how libstdc++ was built in previous releases. I > >> can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor > >> 4.9.0. A problematic libstdc++ from earlier releases causes genmatch > >> to loop in stage 1. > > > > I see. A bootstrap with IPA ICF disabled did not succeed but runs into > > the same issue in stage2. So I wonder if the issue is latent for much > > longer and genmatch just exposes it now. > > > > I'll see if I can remove the use of std::map from genmatch as a > > workaround. > > I assume that this is a pervasive issue in the interaction between GCC > optimizations and AIX -G linker option. Something expects the second > call to point to a different implementation. I don't know if the > address in the TOC (GOT) is wrong or something expects the second call > to use a different TOC, but there is a circular reference. > > I am going to apply a patch to GCC to not build libstdc++ with -G. I > also will apply it to GCC 4.9 branch. I was hoping that it could be > included in GCC 4.9.2, but I needed to test it thoroughly and Jakub > beat me with the release. As it might only affect static linking(?) it might be a good idea to run the libstdc++ testsuite with statically linking libstdc++ (-static-libstdc++) before/after such change? That is, make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=unix/-static-libstdc++" (hopefully that is able to add to link flags and not compile-flags only) Thanks, Richard. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-10-31 8:19 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-24 23:37 genmatch infinite loop during bootstrap on AIX 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 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
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).