Message ID | 3184807.aeNJFYEL58@arcturus |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:38f:b0:2d5:3c95:9e21 with SMTP id 15csp2021434pxh; Tue, 16 Aug 2022 06:57:34 -0700 (PDT) X-Google-Smtp-Source: AA6agR5WAcWW5t0VJYNCfMhStN1FM6gVOE8qz0zeaVbKqhdy9UM5X+/mgrHIAdqq3Pl80MHrB3MR X-Received: by 2002:a17:906:98c9:b0:730:a23e:2785 with SMTP id zd9-20020a17090698c900b00730a23e2785mr13598325ejb.622.1660658254401; Tue, 16 Aug 2022 06:57:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660658254; cv=none; d=google.com; s=arc-20160816; b=dUuXOXgHnbJavFz5osFxK2LchsK7mtQGBXtMLLJ72se+5tJDubi4RNBPjDDUwNqjRu qqXzt7//dPuY9MFbNOp5mUegVVumg3HKX3IrWbmxAKvxZhTeP+T7eZO5MKMSh1BNmk4M 68ubv4YjUynHjpV1L0rw29uyuQW5xAyxTIgfElbBNan6pAZrOr5Igqtp6BqpX7RHqPx/ Qc192KUe8/t3bQCVGj7hgwZa3MM0AwqOKYJJg54Z+cGo4EO0sJMQAyAiDnOYbJhPVXjc 3MEj63GygTLOhCWG0hQFfjMvICRZdlFfTQUOFVbCnGjSiUtlaMBcdAb2MCOLGh29HZDd 2+Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:to :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=Jsu/2BcfgtB0Pc+lR7jYMFyW05j713NIu4OsWaRecBY=; b=UcT9bBLpSTkJ4J/td/mrh+xb5y2bdmYuhDBgKqwbT0OyCVsuyFtiG/eX400Jyid+cP CpcS52SOUoW3TRIra3UVQpWa3a5nIOXPAkaUcJy7eqviLC5C/Td8FspDLL/Ko2V2f9K+ IRJ71dY6eNCanzID4Q+4vBPOK8sseitPQ4fl1OlE698qcpbCK/jHIKz/JhnYS9UPFVBT fE30voW3BHXqTXSQjNGk6/vRR3TsZuvdgsNvk3SH2IbxWY/MN0eDNWWtR2Wvc4VRlUvy mOmESNwmUVdziVxut4je1ezSqYAMoQ4ySxzxkUQuC9CEglcT9/zsWLldkj7KkayElPHF /h6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=kSKjXt7q; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id h4-20020a1709066d8400b007317a6beb8fsi7851544ejt.502.2022.08.16.06.57.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 06:57:34 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=kSKjXt7q; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D475C3857B92 for <ouuuleilei@gmail.com>; Tue, 16 Aug 2022 13:57:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D475C3857B92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1660658239; bh=Jsu/2BcfgtB0Pc+lR7jYMFyW05j713NIu4OsWaRecBY=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=kSKjXt7q1OsGsC9yJQnlSNDcjamaa3pAjBS9AJ2SZVW85NrLsvX7qXK9AolLLSUau gglLS7xsDKxeDc+kZAMBEJnqTOrZCwGspU0kmlOJ68rkpYEAi+WBUM6rOQf2214HJv RNQkZGogbmdnEYBB6wGj1ikljpQgkUpe+kDjQwVM= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 0341438582BF for <gcc-patches@gcc.gnu.org>; Tue, 16 Aug 2022 13:56:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0341438582BF Received: by mail-wm1-x32c.google.com with SMTP id ay39-20020a05600c1e2700b003a5503a80cfso5422564wmb.2 for <gcc-patches@gcc.gnu.org>; Tue, 16 Aug 2022 06:56:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc; bh=Jsu/2BcfgtB0Pc+lR7jYMFyW05j713NIu4OsWaRecBY=; b=lxNp9lCPxIPWQj2y2zMhdciI+GTMmJ9AaAMrJk91tUyznWqlxn1cJts/MVLbUx1UbC YK3TDvao8yaOLGCYFnfFXyU/YYh9qU1ThUKgrD5mYvfTlSUtGwvM+opa+G+ou9TjR2zh No/CwYWHfjTRinDx1JDzpobWMIpL4Xl27b3lK3fKy7Ui+bSCVPwMzOSKLEctXu94y95p M7+6/W96emhPLJWz/ST+soji7CXk333uGs8aKaKBsTnBY+jjj2w27Wp63Gmks0HPRXAw 6bsUWpju+I+tkv0wgkOkH0Q8+8CQzNkhqSoCuN/X7ar6xmHeLAyBDn5kA2UeJTGacZ/c 91Pw== X-Gm-Message-State: ACgBeo32jFmwjbMyEPZd79c/O85Is8mKUtlaWLoDrudrvE65XzzFQ8/u Zq2zD2c6Cfo2Ww+WGl5HmDojd2hgY1oaAg== X-Received: by 2002:a05:600c:1d08:b0:3a5:b7ee:91c9 with SMTP id l8-20020a05600c1d0800b003a5b7ee91c9mr14144809wms.114.1660658175660; Tue, 16 Aug 2022 06:56:15 -0700 (PDT) Received: from arcturus.localnet ([2a01:cb10:8647:7500:603a:7837:893c:1da4]) by smtp.gmail.com with ESMTPSA id s3-20020a5d4243000000b002206b4df832sm10337316wrr.110.2022.08.16.06.56.14 for <gcc-patches@gcc.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 06:56:14 -0700 (PDT) X-Google-Original-From: Eric Botcazou <ebotcazou@adacore.com> To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix bogus -Wstringop-overflow warning in Ada Date: Tue, 16 Aug 2022 15:56:16 +0200 Message-ID: <3184807.aeNJFYEL58@arcturus> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3190913.44csPzL39Z" Content-Transfer-Encoding: 7Bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Eric Botcazou via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Eric Botcazou <botcazou@adacore.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1741326390234068581?= X-GMAIL-MSGID: =?utf-8?q?1741326390234068581?= |
Series |
Fix bogus -Wstringop-overflow warning in Ada
|
|
Commit Message
Eric Botcazou
Aug. 16, 2022, 1:56 p.m. UTC
Hi, the following bogus warning: In function 'lto26', inlined from 'main' at /home/eric/gnat/bugs/V721-018/b~lto26.adb:237:7: lto26.adb:11:13: warning: writing 1 byte into a region of size 0 [-Wstringop- overflow=] 11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1); | ^ lto26.adb: In function 'main': lto26.adb:11:50: note: at offset -9223372036854775808 into destination object 'A.0' of size 7 11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1); | ^ comes from a discrepancy between get_offset_range, which uses a signed type, and handle_array_ref, which uses an unsigned one, to do offset computations. Tested on x86-64/Linux, OK for the mainline? 2022-08-16 Eric Botcazou <ebotcazou@adacore.com> * pointer-query.cc (handle_array_ref): Fix handling of low bound. 2022-08-16 Eric Botcazou <ebotcazou@adacore.com> * gnat.dg/lto26.adb: New test. * gnat.dg/lto26_pkg1.ads, gnat.dg/lto26_pkg1.adb: New helper. * gnat.dg/lto26_pkg2.ads, gnat.dg/lto26_pkg2.adb: Likewise.
Comments
On Tue, Aug 16, 2022 at 3:57 PM Eric Botcazou via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Hi, > > the following bogus warning: > > In function 'lto26', > inlined from 'main' at /home/eric/gnat/bugs/V721-018/b~lto26.adb:237:7: > lto26.adb:11:13: warning: writing 1 byte into a region of size 0 [-Wstringop- > overflow=] > 11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1); > | ^ > lto26.adb: In function 'main': > lto26.adb:11:50: note: at offset -9223372036854775808 into destination object > 'A.0' of size 7 > 11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1); > | ^ > > comes from a discrepancy between get_offset_range, which uses a signed type, > and handle_array_ref, which uses an unsigned one, to do offset computations. > > Tested on x86-64/Linux, OK for the mainline? Hmm, can we instead do if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd)) { const offset_int lb = offset_int::from (lowbnd, SIGNED); ... ? In particular interpreting the unsigned lowbnd as SIGNED when not wlb.get_precision () < TYPE_PRECISION (sizetype), offset_int should handle all positive and negative byte offsets since it can also represent them measured in bits. Unfortunately the wide_int classes do not provide the maximum precision they can handle. That said, the check, if any, should guard the whole orng adjustment, no? (in fact I wonder why we just ignore lowbnd if it doesn't fit or is variable...) > > > 2022-08-16 Eric Botcazou <ebotcazou@adacore.com> > > * pointer-query.cc (handle_array_ref): Fix handling of low bound. > > > 2022-08-16 Eric Botcazou <ebotcazou@adacore.com> > > * gnat.dg/lto26.adb: New test. > * gnat.dg/lto26_pkg1.ads, gnat.dg/lto26_pkg1.adb: New helper. > * gnat.dg/lto26_pkg2.ads, gnat.dg/lto26_pkg2.adb: Likewise. > > -- > Eric Botcazou
> Hmm, can we instead do > > if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd)) > { > const offset_int lb = offset_int::from (lowbnd, SIGNED); > ... > > ? Apparently not: In file included from /home/eric/cvs/gcc/gcc/coretypes.h:460, from /home/eric/cvs/gcc/gcc/pointer-query.cc:23: /home/eric/cvs/gcc/gcc/wide-int.h: In instantiation of 'wide_int_ref_storage<SE, HDP>::wide_int_ref_storage(const T&) [with T = tree_node*; bool SE = false; bool HDP = true]': /home/eric/cvs/gcc/gcc/wide-int.h:782:15: required from 'generic_wide_int<T>::generic_wide_int(const T&) [with T = tree_node*; storage = wide_int_ref_storage<false>]' /home/eric/cvs/gcc/gcc/pointer-query.cc:1803:46: required from here /home/eric/cvs/gcc/gcc/wide-int.h:1024:48: error: incomplete type 'wi::int_traits<tree_node*>' used in nested name specifier 1024 | : storage_ref (wi::int_traits <T>::decompose (scratch, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ 1025 | wi::get_precision (x), x)) | ~~~~~~~~~~~~~~~~~~~~~~~~~ And: const offset_int lb = wi::to_offset (lowbnd); compiles but does *not* fix the problem since it does a zero-extension. [Either extension is fine, as long as it's the same in get_offset_range]. > In particular interpreting the unsigned lowbnd as SIGNED when > not wlb.get_precision () < TYPE_PRECISION (sizetype), offset_int > should handle all positive and negative byte offsets since it can > also represent them measured in bits. Unfortunately the > wide_int classes do not provide the maximum precision they can > handle. That said, the check, if any, should guard the whole > orng adjustment, no? (in fact I wonder why we just ignore lowbnd > if it doesn't fit or is variable...) Yes, tree_fits_uhwi_p (or tree_fits_shwi_p) is bogus here, but the test against INTEGER_CST is used everywhere else and should be good enough.
On Wed, Aug 17, 2022 at 3:38 PM Eric Botcazou <botcazou@adacore.com> wrote: > > > Hmm, can we instead do > > > > if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd)) > > { > > const offset_int lb = offset_int::from (lowbnd, SIGNED); > > ... > > > > ? > > Apparently not: > > In file included from /home/eric/cvs/gcc/gcc/coretypes.h:460, > from /home/eric/cvs/gcc/gcc/pointer-query.cc:23: > /home/eric/cvs/gcc/gcc/wide-int.h: In instantiation of > 'wide_int_ref_storage<SE, HDP>::wide_int_ref_storage(const T&) [with T = > tree_node*; bool SE = false; bool HDP = true]': > /home/eric/cvs/gcc/gcc/wide-int.h:782:15: required from > 'generic_wide_int<T>::generic_wide_int(const T&) [with T = tree_node*; storage > = wide_int_ref_storage<false>]' > /home/eric/cvs/gcc/gcc/pointer-query.cc:1803:46: required from here > /home/eric/cvs/gcc/gcc/wide-int.h:1024:48: error: incomplete type > 'wi::int_traits<tree_node*>' used in nested name specifier > 1024 | : storage_ref (wi::int_traits <T>::decompose (scratch, > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ > 1025 | wi::get_precision (x), > x)) > | > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > And: > > const offset_int lb = wi::to_offset (lowbnd); > > compiles but does *not* fix the problem since it does a zero-extension. Meh. OK, eventually would need "indirection" through a wide-int then. Like offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd))) ? > [Either extension is fine, as long as it's the same in get_offset_range]. I think it should extend according to sing of lowbnd? Or does Ada use an unsigned lowbnd to represent a signed value here? At least that's what I had issues with with your patch. > > In particular interpreting the unsigned lowbnd as SIGNED when > > not wlb.get_precision () < TYPE_PRECISION (sizetype), offset_int > > should handle all positive and negative byte offsets since it can > > also represent them measured in bits. Unfortunately the > > wide_int classes do not provide the maximum precision they can > > handle. That said, the check, if any, should guard the whole > > orng adjustment, no? (in fact I wonder why we just ignore lowbnd > > if it doesn't fit or is variable...) > > Yes, tree_fits_uhwi_p (or tree_fits_shwi_p) is bogus here, but the test > against INTEGER_CST is used everywhere else and should be good enough. > > -- > Eric Botcazou > >
> Meh. OK, eventually would need "indirection" through a wide-int then. > Like > > offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd))) That would be OK if get_offset_range did the same, but it does not since it forces a sign-extension whatever the sign of a large type: signop sgn = SIGNED; /* Only convert signed integers or unsigned sizetype to a signed offset and avoid converting large positive values in narrower types to negative offsets. */ if (TYPE_UNSIGNED (type) && wr[0].get_precision () < TYPE_PRECISION (sizetype)) sgn = UNSIGNED; > I think it should extend according to sing of lowbnd? Or does Ada > use an unsigned lowbnd to represent a signed value here? At least > that's what I had issues with with your patch. It uses sizetype like everyone else and the signedness was forced on it because of the POINTER_PLUS_EXPR thing, i.e. it was signed before.
On Thu, Aug 18, 2022 at 9:54 AM Eric Botcazou <botcazou@adacore.com> wrote: > > > Meh. OK, eventually would need "indirection" through a wide-int then. > > Like > > > > offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd))) > > That would be OK if get_offset_range did the same, but it does not since it > forces a sign-extension whatever the sign of a large type: > > signop sgn = SIGNED; > /* Only convert signed integers or unsigned sizetype to a signed > offset and avoid converting large positive values in narrower > types to negative offsets. */ > if (TYPE_UNSIGNED (type) > && wr[0].get_precision () < TYPE_PRECISION (sizetype)) > sgn = UNSIGNED; > > > I think it should extend according to sing of lowbnd? Or does Ada > > use an unsigned lowbnd to represent a signed value here? At least > > that's what I had issues with with your patch. > > It uses sizetype like everyone else and the signedness was forced on it > because of the POINTER_PLUS_EXPR thing, i.e. it was signed before. Hmm :/ But that means we _should_ force a sign extension but only from ptrofftype_p ()? That is, your test above should maybe read signop sgn = TYPE_SIGN (type); if (ptrofftype_p (type)) sgn = SIGNED; assuming 'type' is the type of lowbnd > -- > Eric Botcazou > >
> Hmm :/ But that means we _should_ force a sign extension but only > from ptrofftype_p ()? That is, your test above should maybe read > > signop sgn = TYPE_SIGN (type); > if (ptrofftype_p (type)) > sgn = SIGNED; > > assuming 'type' is the type of lowbnd Yes, that's essentially equivalent to what get_offset_range does, but I'm not sure why having two slightly different ways of doing it would be better than a single one here, Maybe replace the call to get_precision in both places with TYPE_PRECSION (type) then?
On Thu, Aug 18, 2022 at 4:46 PM Eric Botcazou <botcazou@adacore.com> wrote: > > > Hmm :/ But that means we _should_ force a sign extension but only > > from ptrofftype_p ()? That is, your test above should maybe read > > > > signop sgn = TYPE_SIGN (type); > > if (ptrofftype_p (type)) > > sgn = SIGNED; > > > > assuming 'type' is the type of lowbnd > > Yes, that's essentially equivalent to what get_offset_range does, but I'm not > sure why having two slightly different ways of doing it would be better than a > single one here, Maybe replace the call to get_precision in both places with > TYPE_PRECSION (type) then? I wasn't aware of the copy in get_offset_range. To cite: wide_int wr[2]; if (!get_range (x, stmt, wr, rvals)) return false; signop sgn = SIGNED; /* Only convert signed integers or unsigned sizetype to a signed offset and avoid converting large positive values in narrower types to negative offsets. */ if (TYPE_UNSIGNED (type) && wr[0].get_precision () < TYPE_PRECISION (sizetype)) sgn = UNSIGNED; r[0] = offset_int::from (wr[0], sgn); r[1] = offset_int::from (wr[1], sgn); I guess the main issue here is that the machinery converts to offset_int prematurely and thus needs to do it even when it's not clear in what context (POINTER_PLUS_EXPR offset or not) it is used. The code unfortunately is a bit of a mess and I'm not too familiar with it. I'm OK with your original patch, given the above it's consistent (even if maybe broken). Thanks, Richard. > > -- > Eric Botcazou > > >
diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc index ae561731216..0f0100233c1 100644 --- a/gcc/pointer-query.cc +++ b/gcc/pointer-query.cc @@ -1796,14 +1796,19 @@ handle_array_ref (tree aref, gimple *stmt, bool addr, int ostype, orng[0] = -orng[1] - 1; } - /* Convert the array index range determined above to a byte - offset. */ + /* Convert the array index range determined above to a byte offset. */ tree lowbnd = array_ref_low_bound (aref); - if (!integer_zerop (lowbnd) && tree_fits_uhwi_p (lowbnd)) - { - /* Adjust the index by the low bound of the array domain - (normally zero but 1 in Fortran). */ - unsigned HOST_WIDE_INT lb = tree_to_uhwi (lowbnd); + if (TREE_CODE (lowbnd) == INTEGER_CST && !integer_zerop (lowbnd)) + { + /* Adjust the index by the low bound of the array domain (0 in C/C++, + 1 in Fortran and anything in Ada) by applying the same processing + as in get_offset_range. */ + const wide_int wlb = wi::to_wide (lowbnd); + signop sgn = SIGNED; + if (TYPE_UNSIGNED (TREE_TYPE (lowbnd)) + && wlb.get_precision () < TYPE_PRECISION (sizetype)) + sgn = UNSIGNED; + const offset_int lb = offset_int::from (wlb, sgn); orng[0] -= lb; orng[1] -= lb; }