From patchwork Thu Feb 11 19:44:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 582018 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 ECEE0140C5D for ; Fri, 12 Feb 2016 06:44:45 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=eSelLrJi; 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=E9pHSofEy65+on2pe PfBHlsln0fKDHM2WxHWclxcTFRu/hJZ0bbVaAm+y9rW/WHpxuHLkvINGXT1EzhFn jjYwFWdc4T0bb2sWgekUxSAsLo3Wx6xZnoTmjeExBHIDMVtoGA74UJ+RszDGL6fU nMl9aEMDEG5svGCImo4qwIo0QU= 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=bThx2gxpbNDNE+REkPP7Lj8 JE1k=; b=eSelLrJiU7mG/Xcpriy/b88wyg79EVsHG9Y4GFWXrOxzKj+AoKnM460 T4b6v6s7/UylxurfwsE3MPKkr4T7HAgyQSUBzJQSHZSsNJoFfEbt/PAyzCinoJyc 55uW5nsf+yD9emIYQhQ+lfo4o6Wod6DXUqHcDgpugxmml/BewFTE= Received: (qmail 113452 invoked by alias); 11 Feb 2016 19:44:38 -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 113440 invoked by uid 89); 11 Feb 2016 19:44:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3660 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; Thu, 11 Feb 2016 19:44:36 +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 (Postfix) with ESMTPS id 5A52A5A56; Thu, 11 Feb 2016 19:44:35 +0000 (UTC) Received: from tucnak.zalov.cz ([10.3.113.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1BJiXBh026037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Feb 2016 14:44:34 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u1BJiPNG019489; Thu, 11 Feb 2016 20:44:26 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u1BJiOIJ019488; Thu, 11 Feb 2016 20:44:24 +0100 Date: Thu, 11 Feb 2016 20:44:24 +0100 From: Jakub Jelinek To: Jason Merrill Cc: "Joseph S. Myers" , Marek Polacek , gcc-patches@gcc.gnu.org Subject: Re: [C/C++ PATCH] Fix a -Waddress regression (PR c/69768) Message-ID: <20160211194424.GF3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160211162526.GD3017@tucnak.redhat.com> <56BCD949.9010300@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <56BCD949.9010300@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes Hi! On Thu, Feb 11, 2016 at 01:56:09PM -0500, Jason Merrill wrote: > On 02/11/2016 11:25 AM, Jakub Jelinek wrote: > >+ && !integer_zerop (tree_strip_nop_conversions (op1))) > > Maybe cp_fold rather than tree_strip_nop_conversions? Is it safe to call cp_fully_fold (typeck.c only calls it by that name, not cp_fold) on perhaps type or value dependent argument? E.g. on template int bar () { return "foo1" != (void *) N && "foo2" != (const char *) ((void *) N) && "foo3" != (const char *) ((void *) (N - N)) && "foo4" != (const char *) ((void *) (&e - &e)) && "foo5" != "foo6"; } op1 is NON_DEPENDENT_EXPR. If yes, here is an alternative (that has the same behavior on the testcase as 5.x does). The C FE didn't use to fold it, so I'm preserving its behavior. 2016-02-11 Jakub Jelinek PR c/69768 * c-typeck.c (parser_build_binary_op): Strip nops from integer_zerop arguments for -Waddress warning. * typeck.c (cp_build_binary_op): cp_fully_fold integer_zerop arguments for -Waddress warning. Fix up formatting. * c-c++-common/Waddress-1.c: New test. Jakub --- gcc/c/c-typeck.c.jj 2016-02-11 20:28:51.316491659 +0100 +++ gcc/c/c-typeck.c 2016-02-11 20:29:50.778672554 +0100 @@ -3597,8 +3597,10 @@ parser_build_binary_op (location_t locat of testing for equality or inequality of a string literal with NULL. */ if (code == EQ_EXPR || code == NE_EXPR) { - if ((code1 == STRING_CST && !integer_zerop (arg2.value)) - || (code2 == STRING_CST && !integer_zerop (arg1.value))) + if ((code1 == STRING_CST + && !integer_zerop (tree_strip_nop_conversions (arg2.value))) + || (code2 == STRING_CST + && !integer_zerop (tree_strip_nop_conversions (arg1.value)))) warning_at (location, OPT_Waddress, "comparison with string literal results in unspecified behavior"); } --- gcc/cp/typeck.c.jj 2016-02-11 20:28:51.196493312 +0100 +++ gcc/cp/typeck.c 2016-02-11 20:34:41.124672969 +0100 @@ -4487,9 +4487,12 @@ cp_build_binary_op (location_t location, warning (OPT_Wfloat_equal, "comparing floating point with == or != is unsafe"); if ((complain & tf_warning) - && ((TREE_CODE (orig_op0) == STRING_CST && !integer_zerop (op1)) - || (TREE_CODE (orig_op1) == STRING_CST && !integer_zerop (op0)))) - warning (OPT_Waddress, "comparison with string literal results in unspecified behaviour"); + && ((TREE_CODE (orig_op0) == STRING_CST + && !integer_zerop (cp_fully_fold (op1))) + || (TREE_CODE (orig_op1) == STRING_CST + && !integer_zerop (cp_fully_fold (op0))))) + warning (OPT_Waddress, "comparison with string literal results " + "in unspecified behaviour"); build_type = boolean_type_node; if ((code0 == INTEGER_TYPE || code0 == REAL_TYPE --- gcc/testsuite/c-c++-common/Waddress-1.c.jj 2016-02-11 20:29:50.781672512 +0100 +++ gcc/testsuite/c-c++-common/Waddress-1.c 2016-02-11 20:35:40.299857817 +0100 @@ -0,0 +1,15 @@ +/* PR c/69768 */ +/* { dg-do compile } */ +/* { dg-options "-Waddress" } */ + +static int e; + +int +foo () +{ + return "foo1" != (void *) 0 /* { dg-bogus "comparison with string literal results in unspecified behaviou?r" } */ + && "foo2" != (const char *) ((void *) 0) /* { dg-bogus "comparison with string literal results in unspecified behaviou?r" } */ + && "foo3" != (const char *) ((void *) (10 - 10)) /* { dg-bogus "comparison with string literal results in unspecified behaviou?r" } */ + && "foo4" != (const char *) ((void *) (&e - &e)) /* { dg-warning "comparison with string literal results in unspecified behaviou?r" "" { target c } } */ + && "foo5" != "foo6"; /* { dg-warning "comparison with string literal results in unspecified behaviou?r" } */ +}