From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85339 invoked by alias); 30 Jan 2018 23:25: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 85330 invoked by uid 89); 30 Jan 2018 23:25:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=reservations X-HELO: mail-ot0-f169.google.com Received: from mail-ot0-f169.google.com (HELO mail-ot0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Jan 2018 23:25:50 +0000 Received: by mail-ot0-f169.google.com with SMTP id l5so5525243otj.11 for ; Tue, 30 Jan 2018 15:25:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bR+gdDQgncPCEOGMbcS/G+i9+zgADm4R/isSow1GOlc=; b=AeOUk1B+UVRrlIVl4QpfR5OjHUMx0hzdqOYcPvClFoNp9bPaPubguzrFnOsCqxhjFI 4rB6kg1y8AC68XW1BRxVemoZM8SgPtmdWj5JL1QprTuy1mdzJCmBiVsNNy3IVHLXG9V2 UQJpTiJB4F4aSwj4MPHgfBQxRVVrEwtDMIKKAYOovLin3yVaUai2nnCS00xeRTLXFbLg xbNQXjCbQjLGWzlqpNeDlD+cF2EzDepWcDo/l8ETi3SioMGb5esyQmt3Caum96/yEEuH CzhD4rwP6lW2y3gctZ4wtzufKHYeJZ9fGe3SHeAaXiHaD0mQ4wbwdz2X7WNb9Uur0f8m 5aXA== X-Gm-Message-State: AKwxytebM5LsMEEIQZ5nUYgtIJ6LMmU+7bIzQ8b2AoloEOnZ9pmFH3tQ 8PSywne7q6OdcItH8ZJSjqbsHQ== X-Google-Smtp-Source: AH8x224lGqnKfr9mte4Sjw8Hy1N8pNEur8+lN7sRttbiFvAxcql2W/kP7KO6P+65xFwvoqS6I60B2A== X-Received: by 10.157.38.42 with SMTP id a39mr904730otb.112.1517354748001; Tue, 30 Jan 2018 15:25:48 -0800 (PST) Received: from localhost.localdomain (174-16-107-176.hlrn.qwest.net. [174.16.107.176]) by smtp.gmail.com with ESMTPSA id a6sm2557168oiy.10.2018.01.30.15.25.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 15:25:46 -0800 (PST) Subject: Re: [PR tree-optimization/84047] missing -Warray-bounds on an out-of-bounds index To: Aldy Hernandez , Richard Biener References: <9a52975c-c720-f42f-3564-7b69e361487d@redhat.com> Cc: Jakub Jelinek , Martin Sebor , gcc-patches From: Martin Sebor Message-ID: Date: Tue, 30 Jan 2018 23:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9a52975c-c720-f42f-3564-7b69e361487d@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg02401.txt.bz2 On 01/30/2018 03:11 PM, Aldy Hernandez wrote: > Hi! > > [Note: Jakub has mentioned that missing -Warray-bounds regressions > should be punted to GCC 9. I think this particular one is easy > pickings, but if this and/or the rest of the -Warray-bounds regressions > should be marked as GCC 9 material, please let me know so we can adjust > all relevant PRs.] Let me first say that I have no concern with adopting this patch for GCC 8 (and older) and deferring more comprehensive solutions for the remaining regressions until GCC 9. With that said, as we discussed last week in IRC, the patch I submitted for one of these regressions, bug 83776, also happens to fix one of the two test cases submitted for this bug: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02144.html I put the patch together because it's a P2 bug and has a Target Milestone set to 6.5. I took that to mean that it's expected to be fixed in 8.1 in addition to 7.x and 6.x, but in light of Jakub's reservations and Ady's question above I'm not sure my understanding is correct, or if it is, that there necessarily is consensus to fix them in GCC 8. I also spent some time over the weekend extending my patch to handle the additional test case from comment #2 on bug 84047. That one is also due to the same underlying root cause. I'm close to done with it but I had to set it aside to handle a bug in my own code that was reported yesterday. I mention this because I too would find it helpful if it were made clear whether these regressions are expected to be fixed in GCC 8, so we can focus on the right bugs and avoid duplicating effort. If we want to fix all the reported -Warray-bounds regressions in GCC 8 then I'll finish my patch in progress and post it as a followup. Martin > > This is a -Warray-bounds regression that happens because the IL now has > an MEM_REF instead on ARRAY_REF. > > Previously we had an ARRAY_REF we could diagnose: > > D.2720_5 = "12345678"[1073741824]; > > But now this is represented as: > > _1 = MEM[(const char *)"12345678" + 1073741824B]; > > I think we can just allow check_array_bounds() to handle MEM_REF's and > everything should just work. > > The attached patch fixes both regressions mentioned in the PR. > > Tested on x86-64 Linux. > > OK?