From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55679 invoked by alias); 16 Apr 2015 14:00:56 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 55603 invoked by uid 48); 16 Apr 2015 14:00:51 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65779] [5/6 Regression] undefined local symbol on powerpc [regression] Date: Thu, 16 Apr 2015 14:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg01360.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-04-16 CC| |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- There seems to be multiple issues here. One is a bug in the TARGET_RELOCATABLE handling in the powerpc backend, it emits the LCL and LCF symbols in the IL, but then emits them into the actual assembly only if some conditions are satisfied. If they make it through into debug insns for some reason, that obviously results in the undefined references. Perhaps the target address legitimization should handle those, or if the backend determines that it won't emit the symbols it should scan the IL for any possible debug uses and reset them. I'm afraid there is nothing dwarf2out can do for this. And another thing is why valtrack during DSE2 emits a debug instruction containing this. At *.split2 we have: (insn 36 35 37 2 (set (reg/v:SI 0 0 [orig:239 s2 ] [239]) (lshiftrt:SI (reg/v:SI 3 3 [orig:265 adler ] [265]) (const_int 16 [0x10]))) ../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../powerpc/shared/b (nil)) (debug_insn 37 36 39 2 (var_location:SI s2 (reg/v:SI 0 0 [orig:239 s2 ] [239])) ../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_ (nil)) which LGTM. But then during pro_and_epilogue pass, the insn 36 is removed (perhaps some kind of fast DCE?), and instead a code in the prologue that uses register 0 for something completely different is added, which results in the wrong-debug because the debug insns weren't reset. As a workaround, -fno-var-tracking-assignments should cure this.