From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82455 invoked by alias); 9 Feb 2018 02:46:55 -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 82442 invoked by uid 89); 9 Feb 2018 02:46:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f175.google.com Received: from mail-ot0-f175.google.com (HELO mail-ot0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Feb 2018 02:46:53 +0000 Received: by mail-ot0-f175.google.com with SMTP id 73so6316398oti.12 for ; Thu, 08 Feb 2018 18:46:53 -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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EWog9VuNWrFJXVlFRb8A71daQ/IlRWq4CXfva2ln3DU=; b=Mtap8TrkSVeyHX4dC90s2EJtI+V9ZFBZXxgZhPnbaXibkRPdfYqzJ9/5NwlT4yGnKI ZdURD8OZvh1o/clNavMKKnHO7WGCDFzKR47IpcSJ4blvaeVjxCxfn4aXSYdLxQ3SMJsS NyS1YliWUyR7UH7Iq4jYkj1RRWKG74kulr6QxjrFT24jqvdVz9pwmtBas1H5TrBoSgM9 VzPfYJROE4h9HEszozEVw0WyalCYPPYT/uZg5vLxVmjvAdeAJSLtFuGKNFIaj9e91ksK nuRxNYDmwbLuQSFhRbqCWfi5magNACnwTHsExN6uySFcozoY8vYNXOc7duSO7IRVBfRR 8q9g== X-Gm-Message-State: APf1xPAP4D0XeRm+L2M7Q+Sfh0ElQvcqXNEIX/TaI9nW7jvT6/D2GYAd eRC/Bsk3kClyBsELGCS65VQ= X-Google-Smtp-Source: AH8x2270004m3871/96m27+TJzIqLk8hJJXuY8bIYMcUMec03y9FeoOYwLZHAB64Pr15aXjyv9oR5w== X-Received: by 10.157.114.150 with SMTP id t22mr997603otj.164.1518144411853; Thu, 08 Feb 2018 18:46:51 -0800 (PST) Received: from localhost.localdomain (75-171-255-194.hlrn.qwest.net. [75.171.255.194]) by smtp.gmail.com with ESMTPSA id d9sm429891otc.47.2018.02.08.18.46.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Feb 2018 18:46:50 -0800 (PST) Subject: Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095) To: Gcc Patch List , Jakub Jelinek References: From: Martin Sebor Message-ID: <0e539065-8e8b-8a4a-45b3-c0f251732797@gmail.com> Date: Fri, 09 Feb 2018 02:46: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00479.txt.bz2 Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00076.html On 02/01/2018 04:45 PM, Martin Sebor wrote: > The previous patch didn't resolve all the false positives > in the Linux kernel. The attached is an update that fixes > the remaining one having to do with multidimensional array > members: > > struct S { char a[2][4]; }; > > void f (struct S *p, int i) > { > strcpy (p->a[0], "012"); > strcpy (p->a[i] + 1, p->a[0]); // false positive here > } > > In the process of fixing this I also made a couple of minor > restructuring changes to the builtin_memref constructor to > in order to make the code easier to follow: I broke it out > into a couple of helper functions and called those. > > As with the first revision of the patch, this one is also > meant to be applied on top of > > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html > > Sorry about the late churn. Even though I tested the original > implementation with the Linux kernel the bugs were only exposed > non-default configurations that I didn't build. > > Jakub, you had concerns about the code in the constructor > and about interpreting the offsets in the diagnostics. > I tried to address those in the patch. Please review > the changes and let me know if you have any further comments. > > Thanks > Martin > > On 01/30/2018 04:19 PM, Martin Sebor wrote: >> Testing GCC 8 with recent Linux kernel sources has uncovered >> a bug in the handling of arrays of arrays by the -Wrestrict >> checker where it fails to take references to different array >> elements into consideration, issuing false positives. >> >> The attached patch corrects this mistake. >> >> In addition, to make warnings involving excessive offset bounds >> more meaningful (less confusing), I've made a cosmetic change >> to constrain them to the bounds of the accessed object. I've >> done this in response to multiple comments indicating that >> the warnings are hard to interpret. This change is meant to >> be applied on top of the patch for bug 83698 (submitted mainly >> to improve the readability of the offsets): >> >> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html >> >> Martin >