From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97322 invoked by alias); 6 Mar 2019 17:15:52 -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 97251 invoked by uid 89); 6 Mar 2019 17:15:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.1 spammy=EXPR_P, expr_p, compares, FAILs X-HELO: mail-qk1-f195.google.com Received: from mail-qk1-f195.google.com (HELO mail-qk1-f195.google.com) (209.85.222.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Mar 2019 17:15:38 +0000 Received: by mail-qk1-f195.google.com with SMTP id i5so7224761qkd.13 for ; Wed, 06 Mar 2019 09:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0gjKypDs3qkWmS9N1gpg7VPemg1cpIsme1jTEevQYws=; b=iK+McqOCedaFrkMHdL/kDJ92o2yikOULoHz0/e2hUvvRNDJabg0bjRn6P1Eoj4jVCr F41AwnMbRM1jZ21W7PUTDqUTIHjE4nbjB9lEDpWswXNfwHnVAXPj/z13cNhkSvTi82Lr ZrKpDTvI1BrKPzvy4VzYKNmY4fCIwWWythrgYduQFmGupP/HqTeybeGqQoYhQ1v8GDVB w6IrnP+2awMK5JMIs74RBXqYIqsJYbyXF2Ftb/yjDRT4kwSpM9VM7Oovyvs9+ZOU7IxT 7UT4EFGXd7l72/mlyWDGw3lGKojxMDJX6TVwNm5Vm/06l96MxSsuy1Po+WdhALPr1uhF qwow== Return-Path: Received: from [192.168.0.106] (174-16-104-92.hlrn.qwest.net. [174.16.104.92]) by smtp.gmail.com with ESMTPSA id w127sm1107427qka.46.2019.03.06.09.15.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 09:15:34 -0800 (PST) Subject: Re: [PATCH] Fix up --enable-checking=fold (PR middle-end/89503) To: Jakub Jelinek , Richard Biener Cc: gcc-patches@gcc.gnu.org References: <20190301075411.GM7611@tucnak> <20190301091111.GO7611@tucnak> From: Martin Sebor Message-ID: <577ce309-b5b5-8b28-8c5b-e62657d1d66c@gmail.com> Date: Wed, 06 Mar 2019 18:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20190301091111.GO7611@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00277.txt.bz2 On 3/1/19 2:11 AM, Jakub Jelinek wrote: > On Fri, Mar 01, 2019 at 09:49:03AM +0100, Richard Biener wrote: >> On Fri, 1 Mar 2019, Jakub Jelinek wrote: >>> Some of the builtin folding sets TREE_NO_WARNING flags, which triggers as >>> --enable-checking=fold errors. I think we should allow setting of >>> TREE_NO_WARNING flag when folding, so this patch arranges that. >>> >>> Tested on: >>> ../configure --enable-languages=c,c++,fortran --enable-checking=fold --disable-bootstrap >>> make -jN && make -jN -k check >>> No extra FAILs compared to normal regtest. Ok for trunk? >> >> Hmm, I guess it's OK though for EXPR_P I think we may want the >> TREE_NO_WARNING setter to unshare the tree? Because IIRC it is >> exactly because of tree sharing that we do this kind of checking? > > Maybe, I just wonder if it wouldn't be too expensive. > These TREE_NO_WARNING sets are typically on arguments of builtin functions > so we'd need to unshare the argument (shallow copy) as well as the whole > builtin. Some spots (usually older) in builtins.c do create new trees, > but some TREE_NO_WARNING setting is hidden even in APIs like c_strlen > which actually doesn't return the argument. Plus, many of those functions > that set it are used both during expansion (where supposedly we don't care > about modifying in place) and folding. What a mess? > > So, do you prefer to drop this patch, or just take the || EXPR_P (expr) > part away from it and let Martin (who has added pretty much all of these > TREE_NO_WARNING) fix it later? I read through this thread but I'm not sure I understand the problem (or really the tree sharing business -- different GIMPLE statements sharing the same tree node?) Is the problem here that the checking computes a checksum of the bits in a tree node before folding and compares it to a checksum after folding and setting the NO_WARNING bit in between causes the checking to fail? If that's accurate, if this patch is not the right fix, what would be? Martin > c_strlen is probably the oldest with this > issue and most likely very hard to change; the thing is, it is usually used > during expansion and we heavily rely in that case that it modifies it > in-place and thus doesn't warn multiple times. Just use it also in > fold_builtin_strlen :(. > >>> 2019-03-01 Jakub Jelinek >>> >>> PR middle-end/89503 >>> * fold-const.c (fold_checksum_tree): Ignore TREE_NO_WARNING bit >>> on DECL_P and EXPR_P. > > Jakub >