From patchwork Tue Dec 18 19:03:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 207188 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C21942C0089 for ; Wed, 19 Dec 2012 06:04:25 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1356462266; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=TremotN7cy1A3SE7/CK311DlRDg=; b=ovNE52Hin+8HSVf TeKfPJI5PXSLZKVrDWKvzSELNZaT4+EDeDssNbZIdcvQgqWSZH7mGqJWWxoeTsNx kF9GeL2fW7Svfqvx7Rb6LLo1qSEWFSyILcZYWNXK6RXLpENwjLleMHaRjEgxVae7 59Ux+qGbfsbzzGhujpWvhJrBcHDM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=gkm5gye47x0sTofi2GMvjw1KmOkjDEzObvcLMt21RFOkAuLGYXvKJPHXMkJExo /Nl8MGuoEGs3+tigsCK4VXWd77e1r0SIWNXsVT9nOPCjOZabNsR7HGgxhvvZjO+4 C/jHUgT0ulMNM6kf5eByXCCJC3EPqW8xOe0ge7b30sodg=; Received: (qmail 29989 invoked by alias); 18 Dec 2012 19:04:17 -0000 Received: (qmail 29972 invoked by uid 22791); 18 Dec 2012 19:04:13 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Dec 2012 19:04:04 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBIJ43hQ016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2012 14:04:03 -0500 Received: from zalov.redhat.com (vpn1-7-112.ams2.redhat.com [10.36.7.112]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBIJ404V020006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2012 14:04:02 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qBIJ3x4o007173; Tue, 18 Dec 2012 20:04:00 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qBIJ3xgU007172; Tue, 18 Dec 2012 20:03:59 +0100 Date: Tue, 18 Dec 2012 20:03:58 +0100 From: Jakub Jelinek To: Paolo Bonzini , Alexandre Oliva , Jason Merrill Cc: Eric Botcazou , gcc-patches@gcc.gnu.org Subject: [PATCH] Add gen_lowpart_for_debug (PR debug/55730) Message-ID: <20121218190358.GT2315@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20121217213332.GM2315@tucnak.redhat.com> <50D0286A.2080002@gnu.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50D0286A.2080002@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! On Tue, Dec 18, 2012 at 09:25:14AM +0100, Paolo Bonzini wrote: > Il 17/12/2012 22:33, Jakub Jelinek ha scritto: > > If gen_lowpart_if_possible returns NULL, the default > > rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not > > of the desired mode. I bet in most passes for real insns such rtx is then > > meant to fail recog and thrown away, but for DEBUG_INSN modification that > > doesn't work, since there is no verification (but also e.g. any kind of > > SUBREG is fine). So we can e.g. end up with a (plus:SI (mem:DI ...) (mem:SI ...)) > > or similar and then various passes (in this testcase on s390x reload) can be > > very upset about that. > > Makes sense, and it could even be a wrong-code bug for this simplification: Richi reported another related failure today. During combine, rtl_hooks.gen_lowpart_no_emit is the combine version, which instead of giving up creates (clobber:MODE (const_int 0)). This is slightly less wrong than what the general hook did, but still dwarf2out would ICE when seeing that (with checking, without it just not provide location info). We can easily emit the SUBREG though (e.g. var-tracking itself also calls gen_rtx_raw_SUBREG as last resort) in the DEBUG_INSN operands. Bootstrapped/regtested on x86_64-linux and i686-linux (and on the testcase using -> powerpc64-linux cross), ok for trunk? 2012-12-18 Jakub Jelinek PR debug/55730 * dwarf2out.c (mem_loc_descriptor): Ignore CLOBBER. * valtrack.c (gen_lowpart_for_debug): New function. (propagate_for_debug): Temporarily set rtl_hooks.gen_lowpart_no_emit to gen_lowpart_for_debug. * gcc.dg/debug/pr55730.c: New test. Jakub --- gcc/dwarf2out.c.jj 2012-12-18 11:41:30.000000000 +0100 +++ gcc/dwarf2out.c 2012-12-18 16:38:26.925380294 +0100 @@ -12714,6 +12714,7 @@ mem_loc_descriptor (rtx rtl, enum machin case CONST_VECTOR: case CONST_FIXED: case CLRSB: + case CLOBBER: /* If delegitimize_address couldn't do anything with the UNSPEC, we can't express it in the debug info. This can happen e.g. with some TLS UNSPECs. */ --- gcc/valtrack.c.jj 2012-11-05 15:02:17.000000000 +0100 +++ gcc/valtrack.c 2012-12-18 17:15:18.499375776 +0100 @@ -29,6 +29,24 @@ along with GCC; see the file COPYING3. #include "regs.h" #include "emit-rtl.h" +/* gen_lowpart_no_emit hook implementation for DEBUG_INSNs. In DEBUG_INSNs, + all lowpart SUBREGs are valid, despite what the machine requires for + instructions. */ + +static rtx +gen_lowpart_for_debug (enum machine_mode mode, rtx x) +{ + rtx result = gen_lowpart_if_possible (mode, x); + if (result) + return result; + + if (GET_MODE (x) != VOIDmode) + return gen_rtx_raw_SUBREG (mode, x, + subreg_lowpart_offset (mode, GET_MODE (x))); + + return NULL_RTX; +} + /* Replace auto-increment addressing modes with explicit operations to access the same addresses without modifying the corresponding registers. */ @@ -158,6 +176,7 @@ propagate_for_debug (rtx insn, rtx last, basic_block this_basic_block) { rtx next, loc, end = NEXT_INSN (BB_END (this_basic_block)); + rtx (*saved_rtl_hook_no_emit) (enum machine_mode, rtx); struct rtx_subst_pair p; p.to = src; @@ -165,6 +184,8 @@ propagate_for_debug (rtx insn, rtx last, next = NEXT_INSN (insn); last = NEXT_INSN (last); + saved_rtl_hook_no_emit = rtl_hooks.gen_lowpart_no_emit; + rtl_hooks.gen_lowpart_no_emit = gen_lowpart_for_debug; while (next != last && next != end) { insn = next; @@ -179,6 +200,7 @@ propagate_for_debug (rtx insn, rtx last, df_insn_rescan (insn); } } + rtl_hooks.gen_lowpart_no_emit = saved_rtl_hook_no_emit; } /* Initialize DEBUG to an empty list, and clear USED, if given. */ --- gcc/testsuite/gcc.dg/debug/pr55730.c.jj 2012-12-18 17:08:29.649351676 +0100 +++ gcc/testsuite/gcc.dg/debug/pr55730.c 2012-12-18 17:08:04.000000000 +0100 @@ -0,0 +1,24 @@ +/* PR debug/55730 */ +/* { dg-do compile } */ +/* { dg-options "-w" } */ + +union U +{ + float f; + int i; +}; + +void +foo (unsigned short *x, unsigned char y) +{ + unsigned char g; + union U u; + if (u.i < 0) + g = 0; + else + { + u.f = u.f * (255.0F / 256.0F) + 32768.0F; + g = (unsigned char) u.i; + } + *x = (g << 8) | y; +}