From patchwork Fri Nov 20 15:51:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 546958 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4055B1402B0 for ; Sat, 21 Nov 2015 02:52:08 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=feHOyddD; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=EzgXE2JbP7hpNxjRa 852AiGb3Ui/XpTL7F4Eskv98+TgiLk9g49nl4W/JpJRXirSWtqYwa/hYv8UeRAyX J/T8RprLdrmjZARqLeKHxXWybLFo9XXjkozklxri/8tPXma2yp1lWykeKuTCyKoq m4dPMhTQGpv3OCcCuctLGOmrCM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=lxg2cnbbqYTYzHGNPlG6LpS h6fU=; b=feHOyddDBVMcmY1OsikTIvsZXYs3KyRxG4WY/fXEirvoSMR5ttQcfvF R3lmXWxIeJNAEtEKdn6YdoUGjzybrc/YR3b7wnrs7WZOEZaQAefsFyw467+nbgD3 XliDT/9kcy0OhzWI4bJawI0Wpp14/W6fgSlmGkzXb1VhH1wSr2wo= Received: (qmail 87397 invoked by alias); 20 Nov 2015 15:51:59 -0000 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 Received: (qmail 87370 invoked by uid 89); 20 Nov 2015 15:51:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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; Fri, 20 Nov 2015 15:51:57 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 7EB4AC0C0585; Fri, 20 Nov 2015 15:51:56 +0000 (UTC) Received: from [10.10.116.60] (ovpn-116-60.rdu2.redhat.com [10.10.116.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAKFptuI016506; Fri, 20 Nov 2015 10:51:56 -0500 Subject: Re: PATCH to shorten_compare -Wtype-limits handling To: Martin Sebor , gcc-patches List References: <564D4F77.3010005@redhat.com> <564E2697.9020907@gmail.com> <564E4A36.5040509@redhat.com> Cc: =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= From: Jason Merrill Message-ID: <564F419B.4080507@redhat.com> Date: Fri, 20 Nov 2015 10:51:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564E4A36.5040509@redhat.com> On 11/19/2015 05:16 PM, Jason Merrill wrote: > On 11/19/2015 02:44 PM, Martin Sebor wrote: >> On 11/18/2015 09:26 PM, Jason Merrill wrote: >>> The rs6000 target was hitting a bootstrap failure due to >>> -Werror=type-limits. Since warn_tautological_cmp and other warnings >>> avoid warning if one of the operands comes from a macro, I thought it >>> would make sense to do that here as well. >> >> The also disables the warning for functions that are shadowed by >> macros such as C atomic_load et al. For example, in the program >> below. Is that an acceptable compromise or is there a way to avoid >> this? > > I think it's an acceptable compromise, but see below. > >> At the same time, the change doesn't suppress the warning in other >> cases where I would have expected it to suppress it based on your >> description. For instance here: >> >> unsigned short bar (unsigned short x) >> { >> #define X x >> >> if (x > 0xffff) > > Yes, this is missed because the front end doesn't remember the location > of the use of x; that's one of many location tracking issues. David > Malcolm is working on this stuff. > >> I noticed there is code elsewhere in c-common.c that avoids >> issuing the same warning for system headers (that's the code >> that responsible for issuing the warning for the second test >> case above). > > Hmm, it looks like using expansion_point_if_in_system_header might avoid > the first issue you mention. Thus. commit fb71bf4de520cc4bd11eefb57e50748b4679996f Author: Jason Merrill Date: Thu Nov 19 15:21:47 2015 -0500 * c-common.c (shorten_compare): But look through macros from system headers. diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 068a0bc..fe0a235 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -4651,8 +4651,10 @@ shorten_compare (location_t loc, tree *op0_ptr, tree *op1_ptr, } if (TREE_CODE (primop0) != INTEGER_CST - /* Don't warn if it's from a macro. */ - && !from_macro_expansion_at (EXPR_LOCATION (primop0))) + /* Don't warn if it's from a (non-system) macro. */ + && !(from_macro_expansion_at + (expansion_point_location_if_in_system_header + (EXPR_LOCATION (primop0))))) { if (val == truthvalue_false_node) warning_at (loc, OPT_Wtype_limits, diff --git a/gcc/testsuite/gcc.dg/Wtype-limits2.c b/gcc/testsuite/gcc.dg/Wtype-limits2.c new file mode 100644 index 0000000..92151aa --- /dev/null +++ b/gcc/testsuite/gcc.dg/Wtype-limits2.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-options "-Wtype-limits" } */ +/* { dg-require-effective-target sync_char_short } */ + +#include + +unsigned foo (unsigned char *x) +{ + if (atomic_load (x) > 1000) /* { dg-warning "comparison is always false due to limited range of data type" } */ + return 0; + return 1; +}