From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92539 invoked by alias); 7 Aug 2018 15:02:37 -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 92520 invoked by uid 89); 7 Aug 2018 15:02:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:s5-v6mr X-HELO: mail-qk0-f193.google.com Received: from mail-qk0-f193.google.com (HELO mail-qk0-f193.google.com) (209.85.220.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Aug 2018 15:02:31 +0000 Received: by mail-qk0-f193.google.com with SMTP id b66-v6so11632634qkj.1 for ; Tue, 07 Aug 2018 08:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9zKxBt4TEKU94p26tzMxaBg3RQszYUDjvm0LQtFLXHI=; b=ay08Q/QbSV6m71WcW9UEaszqkwY32Y7KAxKv9AzzyKEfV0zKJIH4LonU/QmPe7xkWT sIYEfSp66bBFn7kvxYWZUetMakD2UCcfbNanmen9B/NspR/BUzRWYfR5jsNECU78NuPv rSERr1OkwpNbAyeSldAyTaa53PCrMoCXIiMlCT7RSkJKjzWLQaKplPFTgZDS0DCsM4XM wd6u8o7vkgWW567BJDA41InmT1284wEAv8hw4SL7IIPZWQaAJiiLltr8nqlEW8JsC8Pb 8b055jZ7OYbZ4Crc8xMFcSDGlMbOOZQt7qRF6go2xg8QZn9MxFdSVAu2vcBAt3xSy+0h eZKg== Return-Path: Received: from localhost.localdomain (97-118-124-30.hlrn.qwest.net. [97.118.124.30]) by smtp.gmail.com with ESMTPSA id b30-v6sm923339qtc.78.2018.08.07.08.02.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 08:02:27 -0700 (PDT) Subject: Re: [PATCH] Make strlen range computations more conservative To: Richard Biener , Jeff Law , Bernd Edlinger , Jakub Jelinek References: <93caaaa6-d6d1-0d4d-c735-b4d9d5bcce07@gmail.com> <8b0e06a1-eea4-418e-35df-c394766bea10@gmail.com> <20180731063839.GC17988@tucnak> <3d6899a7-4536-253e-e082-819301e6ab38@gmail.com> <20180731154812.GF17988@tucnak> <933a1c4a-8cd0-a538-1e7e-d481b7d6ce80@gmail.com> <20180801084015.GH17988@tucnak> <20180803074339.GJ17988@tucnak> <24618943-18a5-4406-9492-c60bd4ec3f08@gmail.com> <7b38bd4f-9fd2-6281-1672-0e00723c2b8f@redhat.com> <1d355cf4-f7cd-eacd-f3bd-94f92948bf4b@gmail.com> <7C66D346-E68C-4070-8786-36E79772921D@suse.de> Cc: GCC Patches From: Martin Sebor Message-ID: <04807865-1762-f5af-699c-a09d8baec29d@gmail.com> Date: Tue, 07 Aug 2018 15:02: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: <7C66D346-E68C-4070-8786-36E79772921D@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00494.txt.bz2 On 08/06/2018 11:45 PM, Richard Biener wrote: > On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote: >> On 08/06/2018 11:40 AM, Jeff Law wrote: >>> On 08/06/2018 11:15 AM, Martin Sebor wrote: >>>>>> These examples do not aim to be valid C, they just point out >> limitations >>>>>> of the middle-end design, and a good deal of the problems are due >>>>>> to trying to do things that are not safe within the boundaries >> given >>>>>> by the middle-end design. >>>>> I really think this is important -- and as such I think we need to >> move >>>>> away from trying to describe scenarios in C because doing so keeps >>>>> bringing us back to the "C doesn't allow XYZ" kinds of arguments >> when >>>>> what we're really discussing are GIMPLE semantic issues. >>>>> >>>>> So examples should be GIMPLE. You might start with (possibly >> invalid) C >>>>> code to generate the GIMPLE, but the actual discussion needs to be >>>>> looking at GIMPLE. We might include the C code in case someone >> wants to >>>>> look at things in a debugger, but bringing the focus to GIMPLE is >> really >>>>> important here. >>>> >>>> I don't understand the goal of this exercise. Unless the GIMPLE >>>> code is the result of a valid test case (in some language GCC >>>> supports), what does it matter what it looks like? The basis of >>>> every single transformation done by a compiler is that the source >>>> code is correct. If it isn't then all bets are off. I'm no GIMPLE >>>> expert but even I can come up with any number of GIMPLE expressions >>>> that have undefined behavior. What would that prove? >>> The GIMPLE IL is less restrictive than the original source language. >>> The process of translation into GIMPLE and optimization can create >>> situations in the GIMPLE IL that can't be validly represented in the >>> original source language. Subobject crossing being one such case, >> there >>> are certainly others. We have to handle these scenarios correctly. >> >> Sure, but a valid C test case still needs to exist to show that >> such a transformation is possible. Until someone comes up with >> one it's all speculation. > > Jakub showed you one wrt CSE of addresses. Sorry, there have been so many examples I've lost track. Can you please copy it here or point to it in the archive? In any event, I would find it reasonable for the strlen optimization to be subject to the same constraints as the aggressive loop optimization. If there are valid test cases where the strlen optimization goes beyond that then let's throttle those. Doing more than that would be arbitrary and result in confusing inconsistencies (as the proposed patch does). For example, these two equivalent functions should continue to result in the same optimal code: extern char b[2][4]; void f (int i) { if (__builtin_strlen (b[i]) >= sizeof b[i]) __builtin_abort (); } void g (int i) { unsigned n = 0; while (b[i][n]) ++n; if (n >= sizeof b[i]) __builtin_abort (); } Martin