From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19254 invoked by alias); 20 Apr 2015 07:47:21 -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 19236 invoked by uid 89); 20 Apr 2015 07:47:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 20 Apr 2015 07:47:19 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3K7lGlu009080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Apr 2015 03:47:17 -0400 Received: from tucnak.zalov.cz (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3K7ZBMn030435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 03:35:12 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t3K7Z9Y3031880; Mon, 20 Apr 2015 09:35:09 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t3K7Z7hV031879; Mon, 20 Apr 2015 09:35:07 +0200 Date: Mon, 20 Apr 2015 07:47:00 -0000 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Cc: Marek Polacek , Dmitry Vyukov Subject: Re: [Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc Message-ID: <20150420073507.GA1725@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150420031049.GB12627@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420031049.GB12627@bubble.grove.modra.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00988.txt.bz2 On Mon, Apr 20, 2015 at 12:40:49PM +0930, Alan Modra wrote: > with the log for the ubsan fails > /src/gcc-5/gcc/testsuite/c-c++-common/ubsan/object-size-10.c:19:11: runtime error: index 128 out of bounds for type 'char [128]' > /src/gcc-5/gcc/testsuite/c-c++-common/ubsan/object-size-10.c:19:11: runtime error: load of address 0x0804a000 with insufficient space for an object of type 'char' > 0x0804a000: note: pointer points here > The issue here is that libsanitizer wants to print some context around the variable, and doesn't try too hard, so if the variable is too close to the end of the RW PT_LOAD, you get different message from what is expected. In your case, most likely the end of the array happens to be exactly at the end of the PT_LOAD segment. So, the fix is either to try harder in ubsan renderMemorySnippet function (it first computes the region it wishes to print, then has if (!IsAccessibleMemoryRange(Min, Max - Min)) { Printf("\n"); return; } ). Supposedly it could, if there are any page boundary crosses in the Min .. Max region lower a little bit (to the page boundary) the end and/or increase to the page boundary the start, and retry with that if it is accessible. Or we'd need to make the testcases that suffer from this accept also the in place of the memory content line, line with ^ marker (don't remember if there is yet another one). > gcc/ > PR debug/65779 > * shrink-wrap.c (insn_uses_reg): New function. > (move_insn_for_shrink_wrap): Remove debug insns using regs set > by the moved insn. > gcc/testsuite/ > * gcc.dg/pr65779.c: New. > > Index: gcc/shrink-wrap.c > =================================================================== > --- gcc/shrink-wrap.c (revision 222160) > +++ gcc/shrink-wrap.c (working copy) > @@ -182,6 +182,21 @@ live_edge_for_reg (basic_block bb, int regno, int > return live_edge; > } > > +static bool > +insn_uses_reg (rtx_insn *insn, unsigned int regno, unsigned int end_regno) > +{ > + df_ref use; > + > + FOR_EACH_INSN_USE (use, insn) > + { > + rtx reg = DF_REF_REG (use); > + > + if (REG_P (reg) && REGNO (reg) >= regno && REGNO (reg) < end_regno) > + return true; > + } > + return false; > +} > + > /* Try to move INSN from BB to a successor. Return true on success. > USES and DEFS are the set of registers that are used and defined > after INSN in BB. SPLIT_P indicates whether a live edge from BB > @@ -340,10 +355,15 @@ move_insn_for_shrink_wrap (basic_block bb, rtx_ins > *split_p = true; > } > > + vec live_bbs; > + if (MAY_HAVE_DEBUG_INSNS) > + live_bbs.create (5); Just wonder if using an auto_vec live_bbs; > + FOR_BB_INSNS_REVERSE (tmp_bb, dinsn) > + { > + if (dinsn == insn) > + break; > + if (DEBUG_INSN_P (dinsn) > + && insn_uses_reg (dinsn, dregno, end_dregno)) > + { > + if (*split_p) > + /* If split, then we will be moving insn into a > + newly created block immediately after the entry > + block. Move the debug info there too. */ > + emit_debug_insn_after (PATTERN (dinsn), bb_note (bb)); > + delete_insn (dinsn); Debug insns should never be deleted, nor moved. You should either reset them (INSN_VAR_LOCATION_LOC (insn) = gen_rtx_UNKNOWN_VAR_LOC (); plus df_insn_rescan_debug_internal (insn);), or try to adjust them based on the instruction setting the register (say, if insn sets the register to some other register + 10 and the other register is still live, you could replace the uses of the register with (plus (the other register) (const_int 10)). > + live_bbs.release (); If live_bbs is auto_vec, this would not be needed. Jakub