From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 442723860C34 for ; Sun, 14 Mar 2021 13:37:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 442723860C34 Received: by mail-ed1-x530.google.com with SMTP id u4so14178192edv.9 for ; Sun, 14 Mar 2021 06:37:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=XPUBebTGNN5a+skPcTjbYMVr2TOsOfx9CFeWCYLuWsk=; b=QLvE8Ba0HFnXp5W8O5IvRAkJJJvaDfHK7fJ+K2d3wn3piv/lac+NaY4FvfgrUBHxla /QgtYsD0kGXki3V+ZndudAQmZq++67JMGVa18r0aSV/FYpkgptnTmvPc5isRTJZ/FKXU w0Nbe5HWBoeVEn6YVFbF9znxUzPltiEnQDIa48w0oVl4mi1AYzjkXdQTlwBcJW515lr3 tg7lku7Dobejc/y9rPjTbJCz1Im5beMchdT2VA2GqO77i+sRmxZKYQohB0xiSImty/1S Mfpk2LfD5ogJRqaR2GjssurAOdrNFr3p7o76NEAwEOlBrDrS5XbGe7HkPv8g/tDCldw7 ZisA== X-Gm-Message-State: AOAM5314E+wpe9RwM0u5Jc1HNC2stpSyxfhMACpc/o5Ga1GsxKsb7inB snzEPCAMdAbwhCOmCwDwuB4= X-Google-Smtp-Source: ABdhPJzizeprYWt+KaBcQwtqAojTLOYsCOm6fcNgmQ0SegcnUC329sWOb0PKztDXMiC8hDYPH3pGyQ== X-Received: by 2002:a05:6402:30a2:: with SMTP id df2mr24680715edb.29.1615729069209; Sun, 14 Mar 2021 06:37:49 -0700 (PDT) Received: from [192.168.178.32] (dynamic-095-115-050-183.95.115.pool.telefonica.de. [95.115.50.183]) by smtp.gmail.com with ESMTPSA id p9sm6082860eds.66.2021.03.14.06.37.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Mar 2021 06:37:48 -0700 (PDT) Date: Sun, 14 Mar 2021 14:37:46 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com> <7926CAF0-69E7-415D-B635-B7C004EC838A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: negative indexes To: Paul Edwards ,gcc@gcc.gnu.org From: Richard Biener Message-ID: X-Spam-Status: No, score=-3.2 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 13:37:51 -0000 On March 14, 2021 9:12:01 AM GMT+01:00, Paul Edwards wrote: >Hi Richard=2E 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=2E The size is the same=2E Absolutely >everything is 32-bits in the program (long, int, char *, >void *, code addresses)=2E > >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=2E And that's exactly what I said=2E Pmode is DImode but ptr_mode is SImode= =2E=20 > >Is your answer still applicable (I don't really understand >your answer=2E :-) )=2E > >Thanks=2E Paul=2E > > > > >-----Original Message-----=20 >From: Richard Biener >Sent: Sunday, March 14, 2021 7:05 PM >To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc=2Egnu=2Eorg >Subject: Re: negative indexes > >On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc=20 > 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,=3DF'-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=2E >>R3 is a pointer to a location in 4 GiB space=2E >>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=2E >> >>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=2E2=2E3 using the i370 target if it makes a difference= =2E > >You are likely missing a fix that sign extends offsets on >Pmode!=3Dptr_mode=20 >targets=2E 3=2E2=2E3 is really old now ;) > >Richard=2E > >>Thanks=2E Paul=2E=20