Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Thu, 30 Oct 2014, David Edelsohn wrote:

 On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener
 richard.guent...@gmail.com wrote:
  On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn dje@gmail.com wrote:
  On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
  richard.guent...@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.

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn dje@gmail.com wrote:
 On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
 richard.guent...@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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener
richard.guent...@gmail.com wrote:
 On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn dje@gmail.com wrote:
 On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
 richard.guent...@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

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

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_stringchar, std::char_traitschar,
 std::allocatorchar ::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::allocatorchar::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:   addir9,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::allocatorchar::allocator() ()
(gdb) disassemble
Dump of assembler code for function _ZNSaIcEC1Ev:
= 0x100984dc +0: addir12,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
twchar_t, std::istreambuf_iteratorwchar_t, std::char_traitswchar_t  
::_M_e
xtract_via_format(std::istreambuf_iteratorwchar_t, 
std::char_traitswchar_t ,
 std::istreambuf_iteratorwchar_t, std::char_traitswchar_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.

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener rguent...@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_stringchar, std::char_traitschar,
 std::allocatorchar ::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::allocatorchar::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:   addir9,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::allocatorchar::allocator() ()
 (gdb) disassemble
 Dump of assembler code for function _ZNSaIcEC1Ev:
 = 0x100984dc +0: addir12,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
 twchar_t, std::istreambuf_iteratorwchar_t, std::char_traitswchar_t 
::_M_e
 xtract_via_format(std::istreambuf_iteratorwchar_t,
 std::char_traitswchar_t ,
  std::istreambuf_iteratorwchar_t, std::char_traitswchar_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 

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn dje@gmail.com wrote:
 On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener rguent...@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_stringchar, std::char_traitschar,
 std::allocatorchar ::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::allocatorchar::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:   addir9,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::allocatorchar::allocator() ()
 (gdb) disassemble
 Dump of assembler code for function _ZNSaIcEC1Ev:
 = 0x100984dc +0: addir12,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
 twchar_t, std::istreambuf_iteratorwchar_t, std::char_traitswchar_t 
::_M_e
 xtract_via_format(std::istreambuf_iteratorwchar_t,
 std::char_traitswchar_t ,
  std::istreambuf_iteratorwchar_t, std::char_traitswchar_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 

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
richard.guent...@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

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

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.

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

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::allocatorchar::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_stringchar,
std::char_traitschar,
std::allocatorchar ::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, 

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
 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...

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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
 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.?

Empty file: success.

Header comment: success.

define_predicates stanza: success.

Any simplify stanza (with or without for loop): HANG.

- David

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
 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.?

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

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

On October 27, 2014 8:13:09 PM CET, David Edelsohn dje@gmail.com wrote:
On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
 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.?

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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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 rguent...@suse.de wrote:
 On October 27, 2014 8:13:09 PM CET, David Edelsohn dje@gmail.com wrote:
On Mon, Oct 27, 2014 at 2:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
 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.?

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

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

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::allocatorchar::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_stringchar, std::char_traitschar,
std::allocatorchar ::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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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 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::allocatorchar::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_stringchar, std::char_traitschar,
std::allocatorchar ::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 

Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener]

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_stringchar, std::char_traitschar,
std::allocatorchar ::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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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 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_stringchar, std::char_traitschar,
std::allocatorchar ::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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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_stringchar, std::char_traitschar,
std::allocatorchar ::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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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_stringchar, std::char_traitschar,
std::allocatorchar ::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

Re: genmatch infinite loop during bootstrap on AIX

[David Edelsohn]

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@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::allocatorchar::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_stringchar, std::char_traitschar,
std::allocatorchar ::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