From patchwork Wed Oct 19 15:32:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 684200 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 3szbYF2jyMz9vGZ for ; Thu, 20 Oct 2016 02:32:49 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=wA0tlrOp; 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=buw3xntyR2NU5vHnm jXb3Nb+4KHC2D3vf5QJcdQoYqSmsXskeAY1zUYdakUpu3xX8NylChDRU0pibA9h8 qZUQ5eANYd9h+Sb1hJyvuWQTymN+Ng1DUdxlgyeA7hFJKsEIMG9TOpNlOk2UGtu+ ie1GgWuiTI1yCCDPXPN6krck/s= 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=iKHbDg/bRVzXd27nzwVp4E1 /XqQ=; b=wA0tlrOpytXgmEzbUeN/5V6gL3MeYH2m34GqK2RDP7/phQBo0ixr00w SS1XfrTzUaOIVSOusN+eV8jrZXAtS/Lz3NWeaEVUh6+JPu05OLFWDJlCXnU5aW7O YKZzo4TBzF7Z07tY7Fb21ipX43cuThpnoWL1e85+nxEfKyVss8fg= Received: (qmail 53273 invoked by alias); 19 Oct 2016 15:32:40 -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 53263 invoked by uid 89); 19 Oct 2016 15:32:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=90000, 87, whatsoever, rightly 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; Wed, 19 Oct 2016 15:32:38 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C39BD67326; Wed, 19 Oct 2016 15:32:36 +0000 (UTC) Received: from reynosa.quesejoda.com (vpn-62-245.rdu2.redhat.com [10.10.62.245]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9JFWY0L017951; Wed, 19 Oct 2016 11:32:34 -0400 Subject: Re: PING: new pass to warn on questionable uses of alloca() and VLAs To: Eric Botcazou , Andreas Schwab References: <5798785F.8020001@redhat.com> <1595501.f2BvEmWqcT@polaris> Cc: gcc-patches@gcc.gnu.org, Jeff Law , christophe.lyon@linaro.org From: Aldy Hernandez Message-ID: <40a675db-261e-2fbf-9760-673bf0e990d8@redhat.com> Date: Wed, 19 Oct 2016 11:32:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1595501.f2BvEmWqcT@polaris> On 10/19/2016 09:16 AM, Eric Botcazou wrote: >> m68k-suse-linux > > visium-elf too. > The attached patch fixes the failures on m68k-suse-linux, visium-elf, and arm-eabi. There were a few problems. One problem is that on lp64 targets (where sizeof(size_t) != sizeof(int)), the warning is slightly different-- and rightly so. I have updated the test to handle both warnings on the respective targets. The other problem is that the following snippet is incorrectly warning on 32-bit targets: if (n > 0 && n < 2000) p = __builtin_alloca (n); Looking at the gimple it seems like another case of VRP failing to give any range information whatsoever. I have xfailed it as another case where Andrew's upcoming work should theoretically fix this. The test is fine on 64-bit targets. Can y'all double check it on your respective targets as I only have a crude cross build? Thanks. Aldy commit 32b629dcab7b78e8181146338c4b077f1d55a0bf Author: Aldy Hernandez Date: Wed Oct 19 11:24:44 2016 -0400 * gcc.dg/Walloca-1.c: Adjust test for !lp64 targets. * gcc.dg/Walloca-2.c: Same. diff --git a/gcc/testsuite/gcc.dg/Walloca-1.c b/gcc/testsuite/gcc.dg/Walloca-1.c index 34a20c3..32e4ab8 100644 --- a/gcc/testsuite/gcc.dg/Walloca-1.c +++ b/gcc/testsuite/gcc.dg/Walloca-1.c @@ -23,7 +23,8 @@ void foo1 (size_t len, size_t len2, size_t len3) char *s = alloca (123); useit (s); // OK, constant argument to alloca - s = alloca (num); // { dg-warning "large due to conversion" } + s = alloca (num); // { dg-warning "large due to conversion" "" { target lp64 } } + // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 26 } useit (s); s = alloca(90000); /* { dg-warning "is too large" } */ diff --git a/gcc/testsuite/gcc.dg/Walloca-2.c b/gcc/testsuite/gcc.dg/Walloca-2.c index 284b34e..4695fda 100644 --- a/gcc/testsuite/gcc.dg/Walloca-2.c +++ b/gcc/testsuite/gcc.dg/Walloca-2.c @@ -8,7 +8,11 @@ g1 (int n) { void *p; if (n > 0 && n < 2000) - p = __builtin_alloca (n); + // FIXME: This is a bogus warning, and is currently happening on + // 32-bit targets because VRP is not giving us any range info for + // the argument to __builtin_alloca. This should be fixed by the + // upcoming range work. + p = __builtin_alloca (n); // { dg-bogus "unbounded use of 'alloca'" "" { xfail { ! lp64 } } } else p = __builtin_malloc (n); f (p); @@ -31,8 +35,9 @@ g3 (int n) void *p; if (n > 0 && n < 3000) { - p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" } - // { dg-message "note:.*argument may be as large as 2999" "note" { target *-*-* } 34 } + p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" "" { target lp64} } + // { dg-message "note:.*argument may be as large as 2999" "note" { target lp64 } 38 } + // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 38 } } else p = __builtin_malloc (n);