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