From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48614 invoked by alias); 7 Jan 2019 09:49:36 -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 48541 invoked by uid 89); 7 Jan 2019 09:49:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Expression, formerly 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 ESMTP; Mon, 07 Jan 2019 09:49:24 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B772EC05090E; Mon, 7 Jan 2019 09:49:23 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B3715D75F; Mon, 7 Jan 2019 09:49:23 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x079nLNf032458; Mon, 7 Jan 2019 10:49:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x079nJX7032457; Mon, 7 Jan 2019 10:49:19 +0100 Date: Mon, 07 Jan 2019 09:49:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723) Message-ID: <20190107094919.GN30353@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00284.txt.bz2 Hi! Apparently my recent patch turned on many non-delegitimized UNSPEC notes (it is checking only note, goes away in release builds, but anyway). The problem is that formerly UNSPECs were diagnosed that way only when inside of CONST, but now also outside of them. The patch keeps ignoring them if they don't have all constant arguments though as before, only tries to handle them if they have all constant arguments and thus normally would appear inside of CONST but we are processing parts of the CONST individually. The following patch fixes it by determining first if they have all CONSTANT_P arguments, and only if they do, follows that with const_ok_for_output_1 verification which can emit this diagnostics. The patch also removes what appears to be a badly applied patch in r255862, the posted patch contained just addition of if (CONST_POLY_INT_P (rtl)) return false; to the function, but added also the hunk I'm removing, so we have now if (targetm.const_not_ok_for_debug_p (rtl)) { if (GET_CODE (rtl) != UNSPEC) { diagnostics; return false; } another diagnostics; return false; } if (CONST_POLY_INT_P (rtl)) return false; if (targetm.const_not_ok_for_debug_p (rtl)) { diagnostics; return false; } Calling it twice will not help in any way. Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested on the testcase with -> sparc-solaris cross-compiler, ok for trunk? 2019-01-07 Jakub Jelinek PR debug/88723 * dwarf2out.c (const_ok_for_output_1): Remove redundant call to const_not_ok_for_debug_p target hook. (mem_loc_descriptor) : Only call const_ok_for_output_1 on UNSPEC and subexpressions thereof if all subexpressions of the UNSPEC are CONSTANT_P. --- gcc/dwarf2out.c.jj 2019-01-05 12:10:36.630753817 +0100 +++ gcc/dwarf2out.c 2019-01-06 21:33:58.583426865 +0100 @@ -14445,13 +14445,6 @@ const_ok_for_output_1 (rtx rtl) if (CONST_POLY_INT_P (rtl)) return false; - if (targetm.const_not_ok_for_debug_p (rtl)) - { - expansion_failed (NULL_TREE, rtl, - "Expression rejected for debug by the backend.\n"); - return false; - } - /* FIXME: Refer to PR60655. It is possible for simplification of rtl expressions in var tracking to produce such expressions. We should really identify / validate expressions @@ -15660,8 +15653,17 @@ mem_loc_descriptor (rtx rtl, machine_mod bool not_ok = false; subrtx_var_iterator::array_type array; FOR_EACH_SUBRTX_VAR (iter, array, rtl, ALL) - if ((*iter != rtl && !CONSTANT_P (*iter)) - || !const_ok_for_output_1 (*iter)) + if (*iter != rtl && !CONSTANT_P (*iter)) + { + not_ok = true; + break; + } + + if (not_ok) + break; + + FOR_EACH_SUBRTX_VAR (iter, array, rtl, ALL) + if (!const_ok_for_output_1 (*iter)) { not_ok = true; break; Jakub