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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CFB5B3857007 for ; Sun, 11 Sep 2022 08:04:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFB5B3857007 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662883495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/Z0jaBcKXZz8Bfvd3ZjPvYDpyi7r/S+vpoI5Dti5Hg=; b=cwPjuIimal6qoUU332eQh8DdONvicDRCh//BEhd4WYGu5beYffYma9ipg8pA3WYjJXf0aT kZ5x4my//f/NZnKvzZGqm8ydsh2ZOhmYU5wCr9Brzfh0ipbkBTToR1URrYTxuLFXyW8m+P 342RFjO2A1gUiu6be+AD0lpZSwIMRLw= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-249-OnLtP4r_MZu9-jmI7vo1aQ-1; Sun, 11 Sep 2022 04:04:53 -0400 X-MC-Unique: OnLtP4r_MZu9-jmI7vo1aQ-1 Received: by mail-ed1-f72.google.com with SMTP id v11-20020a056402348b00b004516e0b7eedso1388213edc.8 for ; Sun, 11 Sep 2022 01:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date; bh=L/Z0jaBcKXZz8Bfvd3ZjPvYDpyi7r/S+vpoI5Dti5Hg=; b=vD0kPlEE5ETRVe+1tBS9qddmQ6J0sPqlY6qr7lIxqaz4BpnPah476NoaH0F0tekmoY ZUYtAdcMBU8xRW7PveHeXaGcE5WeuMAYrEKourSibCY00LH0Tg3wsIlHJIvfLCXDmZx/ TJ8hmkKU+koOmRvfLIZ5f4kLRV1XfBUNpyOFbm48tegVV8HK4j4NMqasrg4CG02kcKiJ ROXZOBgUQoTOuRhCz/KDsk8JamiJuXYWdh3siAXSa2dDjU2eHbmqlqTYRIbyIGTcvSxV OjmBa55yDbzhsIGwT6QOUVu7G3GIwwpK41pG3UDpJi/TqV5su9qT4O4ogGjFyOrZlfox K35w== X-Gm-Message-State: ACgBeo34ExjzzkXAW3dEp1wQuVkg+mEM/rCFJ3nM/KuK30Fe01geF+Eh 8K5cFCXKOEhe/lBzfmOKDeWjQTVz3lQ3CwZJrnH3+vZ8ysIUjAGyFyVAOh1VgY7isnWYzzuaeUB zpincXRgryLDVt1PcrQ== X-Received: by 2002:a17:906:9746:b0:74f:945a:5d41 with SMTP id o6-20020a170906974600b0074f945a5d41mr15187881ejy.63.1662883492393; Sun, 11 Sep 2022 01:04:52 -0700 (PDT) X-Google-Smtp-Source: AA6agR4uWoUoHan4cH95/bWHxUOgl5gfDPCDGLSmnD0gRepnk21hv2ai3u8Cr1ro/cuxK/3uUl07Hg== X-Received: by 2002:a17:906:9746:b0:74f:945a:5d41 with SMTP id o6-20020a170906974600b0074f945a5d41mr15187871ejy.63.1662883492132; Sun, 11 Sep 2022 01:04:52 -0700 (PDT) Received: from t14s.localdomain ([82.141.252.180]) by smtp.gmail.com with ESMTPSA id b4-20020aa7df84000000b0044dbecdcd29sm3550285edy.12.2022.09.11.01.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Sep 2022 01:04:51 -0700 (PDT) Message-ID: <359c4cd9b3afcaffd974883847073bc41aae3e4e.camel@redhat.com> Subject: Re: [PATCH] analyzer: consider empty ranges and zero byte accesses [PR106845] From: David Malcolm To: Tim Lange , gcc-patches@gcc.gnu.org Date: Sun, 11 Sep 2022 09:04:51 +0100 In-Reply-To: <20220910221952.99541-1-mail@tim-lange.me> References: <20220910221952.99541-1-mail@tim-lange.me> User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, 2022-09-11 at 00:19 +0200, Tim Lange wrote: > Hi, >=20 > see my patch below for a fix of pr106845.=C2=A0 I decided to allow > bit_ranges > and byte_ranges to have a size of zero and rather only add an > assertion > to the functions that assume a non-zero size.=C2=A0 That way is more > elegant in > the caller than restricting byte_range to only represent non-empty > ranges. Agreed. >=20 > - Tim >=20 > This patch adds handling of empty ranges in bit_range and byte_range > and > adds an assertion to member functions that assume a positive size. > Further, the patch fixes an ICE caused by an empty byte_range passed > to > byte_range::exceeds_p. >=20 > Regression-tested on Linux x86_64. >=20 Thanks - the patch is OK for trunk, though... [...snip...] >=20 > +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c > @@ -0,0 +1,11 @@ > +int buf_size; > + > +int > +main (void) > +{ > +=C2=A0 char buf[buf_size]; > + > +=C2=A0 __builtin_memset (&buf[1], 0, buf_size); > + > +=C2=A0 return 0; > +} ...it took me a moment to realize that the analyzer "sees" that this is "main", and thus buf_size is 0. Interestingly, if I rename it to not be "main" (and thus buf_size could be non-zero), we still don't complain: https://godbolt.org/z/PezfTo9Mz Presumably this is a known limitation of the symbolic bounds checking? Thanks Dave