Re: genmatch infinite loop during bootstrap on AIX

[Richard Biener <rguenther at suse dot de>]

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.