From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29382 invoked by alias); 29 Oct 2014 13:24:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29367 invoked by uid 89); 29 Oct 2014 13:24:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f53.google.com Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 29 Oct 2014 13:24:25 +0000 Received: by mail-wg0-f53.google.com with SMTP id b13so1853013wgh.40 for ; Wed, 29 Oct 2014 06:24:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.90.34 with SMTP id bt2mr36378967wib.58.1414589062610; Wed, 29 Oct 2014 06:24:22 -0700 (PDT) Received: by 10.194.20.74 with HTTP; Wed, 29 Oct 2014 06:24:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Oct 2014 13:31:00 -0000 Message-ID: Subject: Re: genmatch infinite loop during bootstrap on AIX From: Richard Biener To: David Edelsohn Cc: Richard Biener , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg03070.txt.bz2 On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn wrote: > On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener 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, >>> std::allocator >::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=, >>> argv=) 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::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::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 > >>>::_M_e >> xtract_via_format(std::istreambuf_iterator> std::char_traits >, >> std::istreambuf_iterator >, >> 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