From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 0D14B3858C3A for ; Mon, 25 Oct 2021 20:55:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D14B3858C3A Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-N_Wugb7OPOG10jDvYxDnHQ-1; Mon, 25 Oct 2021 16:55:08 -0400 X-MC-Unique: N_Wugb7OPOG10jDvYxDnHQ-1 Received: by mail-qt1-f198.google.com with SMTP id f7-20020a05622a104700b002a7bc1702d3so6394148qte.20 for ; Mon, 25 Oct 2021 13:55:08 -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=ApTPXTrudTTLTC55qzIndhPZ0i70X3GtaydDJmr27sc=; b=oKJQz8o7hEEnLRZDhj+CP6SVibbaHfUQCDBL6/DBxYR9n/FXCKHwFOmbu6O7dFG0Qk aLoR7mbwM6P4HVcg0Re0cLn9TuNmEPbQ+0bpywmueoj//lE53nyGTNsPKL3nR3/c5a3/ +seNBxpkY9qQnwYismH+4IUwcYNLywqLO9z1mL9cDJ4afEBVqvJaYJ7m/B3jK41xrQ+T d6zg5H1wAtc5FVG38bRhsTUPIIyKqv7lXsK4Suaxrn1LEx1qcFPhF5l/xJc1UFgm3ifH WGeLX/99QJHube2q8vEVYoU9AuLq3V7mTmv3vs5t9q5AZwySqrEMm7EEIEdqW6u4wuFL s+iQ== X-Gm-Message-State: AOAM531rdS4KuXJd/J2/5P6yPz9es7V4qoNquF2Uyef9XZprpuDAtUJD h6aG7UoFKvHcd98/GAKzlRb6a6Y1AR1TXWC/u5dL6Ljmu0Ohv3rZAf0bui3BLw2bumSYNoNfk5a KxFOgmwzsaX7CpOObrku7BefXySlf8hs6GSuNcfnxJbV9O58hKzBeKej8H8czitKlrP6QAQ== X-Received: by 2002:a05:6214:300c:: with SMTP id ke12mr5282162qvb.41.1635195307678; Mon, 25 Oct 2021 13:55:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHbB2BolbgWrdQ/gk8iHSUjbwh05TB0EffLylQLbhRXGxcJyXmFPbeD9k2BBJVm3WqCQnwSw== X-Received: by 2002:a05:6214:300c:: with SMTP id ke12mr5282139qvb.41.1635195307405; Mon, 25 Oct 2021 13:55:07 -0700 (PDT) Received: from [192.168.0.102] ([192.24.49.122]) by smtp.gmail.com with ESMTPSA id g1sm9035240qkd.89.2021.10.25.13.55.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 13:55:06 -0700 (PDT) Subject: Re: Make full use of context-sensitive ranges in access warnings To: Jeff Law , Martin Sebor , gcc-patches References: <1648e958-ece9-dca8-4d47-cded635d48c3@gmail.com> From: Andrew MacLeod Message-ID: Date: Mon, 25 Oct 2021 16:55:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-CA X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 20:55:11 -0000 On 10/25/21 4:24 PM, Jeff Law via Gcc-patches wrote: > > > On 10/25/2021 1:31 PM, Martin Sebor wrote: >> On 10/25/21 12:57 PM, Jeff Law wrote: >>> >>> >>> 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. >> >> The loop computes the size of the "filename2" string so the result >> is 10, no? > Oh, duh.  I'm not sure that Ranger will pick that up though. Absolutely not on its own, unless its globally set earlier by loop analysis or someone else.