From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id BB73A385AC1B for ; Mon, 25 Oct 2021 18:57:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB73A385AC1B Received: by mail-pj1-x102a.google.com with SMTP id u12so4957173pjy.1 for ; Mon, 25 Oct 2021 11:57:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=slqwXOJrClDzMPise5oyCvczLg0DYT+DA8MY17XdK7U=; b=Oo+d1+z+nxwGelunbKD7aWMXTDHUVL9vvlar+pmNE2F8qL6wVvlsp9Ts7KCI+hY6ne xF6ON56XmVgvBNqqUxHufCU2yb/KRz2WiqPEcvJweQFHko+bwAQBmiijbwYPaDCQeeSa YV6BfJvhCgCtptHgIj3bb5WFb+kG5GgiTOGoZbRGLn1hTF+Y5aGaVEJDOnJIXOpWEkUh 1KaDvYAkPKUglbuX9dxIDeEfxPVnvk6n+VmwUHTLfXDnYBdnFYlcw2q0Lz2xIV63YUkS khWg4AK2PE1GtfWKHij+TOExRCOYHfkMFpmae4LuVhkMbWk0Rlm0h9W/my9DU50rcM61 yCZw== X-Gm-Message-State: AOAM530m8a+cg6HJ5nMOtsZ2Pmy9ZkQc0P3/AVFhP/7dC275liNcnEIv Vp7n2dURaQBpKrXu0L24GulLZJkY6t0= X-Google-Smtp-Source: ABdhPJwnkuWg2rii6ZPgtnmnTowAgtjpwfpQevV2kPFXFTK7vMs7qptipZCrV4dWK4mC/SnVtnugyQ== X-Received: by 2002:a17:90a:408f:: with SMTP id l15mr22851156pjg.34.1635188267553; Mon, 25 Oct 2021 11:57:47 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id np18sm6269062pjb.40.2021.10.25.11.57.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 11:57:47 -0700 (PDT) Subject: Re: Make full use of context-sensitive ranges in access warnings To: Martin Sebor , gcc-patches References: <1648e958-ece9-dca8-4d47-cded635d48c3@gmail.com> From: Jeff Law Message-ID: Date: Mon, 25 Oct 2021 12:57:46 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <1648e958-ece9-dca8-4d47-cded635d48c3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:57:50 -0000 On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote: > Somewhat belatedly following Aldy's lead on finishing > the conversion to Ranger, the attached patch modifies > gimple-ssa-warn-access and other passes that use > the pointer_query machinery to provide Ranger with > the statement it's being called to determine ranges for. > The changes are almost completely mechanical, involving > passing a GIMPLE statement around (and a range_query > pointer) all the way into the bowels of the pointer_query > class to make them available when range info is being > determined. > > There might be some overlap with Aldy's tree-ssa-strlen.c > changes to do the same there.  I'll deal with any conflicts > when it comes time to commit the work. > > The changes trigger a couple of -Wstringop-overread instances > in libstdc++ tests.  The warnings look valid for the IL but > the code they're in is unreachable.  One of the tests already > suppresses -Wstringop-overflow so also suppressing > -Wstringop-overread doesn't seem out of line. > > Tested on x86_64-linux. > > Martin > > PS The warning for the u8path-char8_t.cc test is this: > > /ssd/test/build/gcc-test/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:355: > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned > int)' reading between 16 and 4611686018427387903 bytes from a region > of size 10 [-Wstringop-overread] > > The IL for it is below.  The loop iN BB 3 exits with __i_22 equal > to 10 so BBs 5, 6 and 7 are unreachable.  It's surprising to me > that the loop isn't optimized into something better (like a MEM > array assignment or memcpy). > >   [local count: 1073741824]: >   MEM[(struct basic_string *)&s1] ={v} {CLOBBER}; >   MEM[(struct _Alloc_hider *)&s1] ={v} {CLOBBER}; >   MEM[(struct _Alloc_hider *)&s1]._M_p = &s1.D.30357._M_local_buf; > >   [local count: 8687547547]: >   # __i_109 = PHI <__i_22(3), 0(2)> >   __i_22 = __i_109 + 1; >   _24 = MEM[(const char_type &)"filename2" + __i_22 * 1]; >   if (_24 != 0) >     goto ; [89.00%] >   else >     goto ; [11.00%] > >   [local count: 1073741824]:   <<< __i_22 == 10 here >   if (__i_22 > 15) >     goto ; [33.00%] >   else >     goto ; [67.00%] > >   [local count: 354334802]: >   if (__i_22 > 4611686018427387903) >     goto ; [0.04%] >   else >     goto ; [99.96%]   >>> __i_22 in [16, 4611686018427387903] > >   [local count: 141736]: >   std::__throw_length_error ("basic_string::_M_create"); > >   [local count: 354193066]: >   _85 = __i_109 + 2; >   _42 = operator new (_85); >   s1._M_dataplus._M_p = _42; >   s1.D.30357._M_allocated_capacity = __i_22; >   __builtin_memcpy (_42, "filename2", __i_22);   << -Wstringop-overread Do you mean __i_22 == 16 earlier?  I don't see how it's restricted to 10. I would have expected to have a global range for i_22 of [0,16] which in turn should have allowed the optimizers to remove bb5 and bb6.  Not sure if that'd fix your overread though. OK.  I'll let you and Aldy coordinate since y'all may be hitting some of the same bits. jeff