From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69286 invoked by alias); 19 Oct 2016 16:22:01 -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 69265 invoked by uid 89); 19 Oct 2016 16:22:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=upcoming X-HELO: mail-qk0-f171.google.com Received: from mail-qk0-f171.google.com (HELO mail-qk0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 16:21:50 +0000 Received: by mail-qk0-f171.google.com with SMTP id f128so42209084qkb.1 for ; Wed, 19 Oct 2016 09:21:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tD3YFphs4Ey2ZDmVBIkT1Gvvqvtqsk24nzwYJl6mCFQ=; b=dAIvGWYrpu11Ty4u9s8nVOgv+0JqlEdrZ/SP4rejwE+dQzl4jxhgjigz0z25wKisER 1FRTdvyPPgsewhTfSE9MBClHznKOHZl/gm0I3I/gcgG6OA5/2X56LHgbucqks5huXzlb Yc/NPqRkfKKofZicv7BQ7g+HiuYVZZ8GT4cs3SIhap7BpGQTyzovqqJWyNBh7IR3DLMt Qvo7LRpNUo8lcSzHSZdefotM+DJaVm6CkeQIPJxJ/TyBu0BbxQfWpG07tKhrDQOVWw+y jm17DpTBcGtCuIAUtSiQCCTREC3ZgGmiaKK343o8ofBKsT6kJNFMQkjgmBsX9US8ENdC Dk4A== X-Gm-Message-State: AA6/9Rlv5TI8ARESo9rSMeQ4LCRDM47Ssnc4z34hqShXjqkYN3unLMWDvIN7bdeqp8XEflEnFXJDr+EY19IN6BM3 X-Received: by 10.233.223.1 with SMTP id t1mr7686661qkf.139.1476894108713; Wed, 19 Oct 2016 09:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.116 with HTTP; Wed, 19 Oct 2016 09:21:47 -0700 (PDT) In-Reply-To: References: <5798785F.8020001@redhat.com> <1595501.f2BvEmWqcT@polaris> <40a675db-261e-2fbf-9760-673bf0e990d8@redhat.com> From: Christophe Lyon Date: Wed, 19 Oct 2016 16:22:00 -0000 Message-ID: Subject: Re: PING: new pass to warn on questionable uses of alloca() and VLAs To: Jeff Law Cc: Aldy Hernandez , Eric Botcazou , Andreas Schwab , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01563.txt.bz2 On 19 October 2016 at 17:55, Jeff Law wrote: > On 10/19/2016 09:32 AM, Aldy Hernandez wrote: >> >> 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? > > OK for the trunk whenever you're ready. > > jeff You are too fast for me :-) I do not have the build trees for all the configurations ready for manual testing... So, I just merged the initial patch and the 2nd one, and started a validation job to make sure the 2nd patch fixes all the regressions observed earlier. It will take a few hours. Christophe