From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 3B56D3860C34 for ; Sun, 14 Mar 2021 11:48:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B56D3860C34 Received: by mail-pj1-x102f.google.com with SMTP id w8so7339282pjf.4 for ; Sun, 14 Mar 2021 04:48:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:subject:date:mime-version :content-transfer-encoding:importance; bh=XB4pDXG9PbcZTOpDVjJpo3rBwWcEYNG9sJGa4yKKotI=; b=CI3JdL3G3whz+0vdR0ud0O5Mq6cX+4lqlCv1OhKHprsD8hpjP4IygJEbiL3Q+n+z/N 0bGJXVXTmvNYKKSyHX/be23plfYKIbB+YGfzxHdn4aDFFkOlUj1wmQmPUCqpHDjFteP4 K3dtoHOAmrR65blQkfOIGmkgRdY/soAJ/uHX4eA20YeUmvNPAFNSlqP5yZhbusV0dn9O EzLZifuWyLJEJ1TiLurmL7gKOrJjDpJPJrjRfzuuRJvcIeswQZQQBoIowtutlp43bO+3 jXGfaIksziQkimm/61IQQcJKzojXSEZeE1bbIof393HUtjlbDa+lxFCXzJeE6bgIw1i4 Ld3Q== X-Gm-Message-State: AOAM531u9R778FaWUL1xbYusQRPJG8xdz0VrU4vVqSoOUsKNQ5bbS0hU MZyx2tMNkyGDWwpL9vRSgODVwjoHZ98= X-Google-Smtp-Source: ABdhPJzDRoibGbHH59Jvm/JDvYlKLsrb0PiEaIhw18dgFGnXguw9lJx7Y1QnMOarzJWT1orIkxp4TQ== X-Received: by 2002:a17:902:dacb:b029:e5:b538:9ce6 with SMTP id q11-20020a170902dacbb02900e5b5389ce6mr6754244plx.8.1615722507044; Sun, 14 Mar 2021 04:48:27 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id q25sm10309686pfh.34.2021.03.14.04.48.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Mar 2021 04:48:26 -0700 (PDT) Message-ID: <44C9A7E5AF59490B8F860471B8E4ECF7@DESKTOP0OKG1VA> From: "Paul Edwards" To: , "Richard Biener" Subject: Re: negative indexes Date: Sun, 14 Mar 2021 22:48:21 +1100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 11:48:29 -0000 Basically the rule (which can be configurable if different machines behave differently) should be (for pure 32-bit code generation): 1. If your machine treats indexes as signed values: a) If the requested index is between -2 GiB and + 2 GiB, fine, do it. b) If the requested index is greater than 2 GiB, you will need to do an addition instead. 2. If your machine treats indexes as as unsigned values: a) If the requested index is less than 0, do a subtraction instead. b) Any non-negative value can be used as an index. Although that logic should only be applied if you have an environment where you don't get saved by address wraparound. If you have a machine that for any reason enforces an attempt to index beyond 4 GiB, or below 0 (instead of just letting the address wrap), then the compiler needs to respect that. This applies to all environments, not just i370. BFN. Paul. -----Original Message----- From: Paul Edwards Sent: Sunday, March 14, 2021 7:12 PM To: gcc@gcc.gnu.org ; Richard Biener Subject: Re: negative indexes Hi Richard. Thanks for your reply, but if I understand you correctly, you are saying this fix is for situations where the size of an integer is different from the size of a pointer? That is not my issue. The size is the same. Absolutely everything is 32-bits in the program (long, int, char *, void *, code addresses). However, since I am running as AMODE 64, if someone attempts to do an index by adding two 32-bit registers together in a single instruction, that reference will actually take effect, and go up into the 4 GiB to 8 GiB region. Is your answer still applicable (I don't really understand your answer. :-) ). Thanks. Paul. -----Original Message----- From: Richard Biener Sent: Sunday, March 14, 2021 7:05 PM To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc.gnu.org Subject: Re: negative indexes On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc wrote: >If I have code like this: > >char foo(char *p) >{ > return (p[-1]); >} > >It generates a negative index, like this: > >* Function foo code > L 2,=F'-1' > L 3,0(11) > SLR 15,15 > IC 15,0(2,3) >* Function foo epilogue > >See that (2,3) - that is adding both R2 + R3. >R3 is a pointer to a location in 4 GiB space. >R2 is now 0xFFFFFFFF > >In 64-bit mode, both of those values are added >together and there is no address wrap, so it >accesses memory above the 4 GiB boundary >(between 4 GiB and 8 GiB to be precise) >which I don't have access to. > >Is there a way of constraining index registers to positive >values? > >I want it to instead generate >ALR 3,2 >to add these two values together using 32-bit arithmetic, >causing truncation at 32 bits, then it can do >IC 15,0(3) >(ie no index) > >I'm using GCC 3.2.3 using the i370 target if it makes a difference. You are likely missing a fix that sign extends offsets on Pmode!=ptr_mode targets. 3.2.3 is really old now ;) Richard. >Thanks. Paul.