From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 1A9453858D29 for ; Mon, 15 Mar 2021 09:23:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A9453858D29 Received: by mail-ej1-x633.google.com with SMTP id p8so64899866ejb.10 for ; Mon, 15 Mar 2021 02:23:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fLqtwFMAYZ+cppZ1hiGjfL0a8GQYyuphzZXbGH3qBzw=; b=CQX99KhFFRPgGNvRte3o6/b7xQUVRXaUuAXbztyoCVGXE72GpgRDIfgLWYOqKxpthh xhoSD5nrn8ovC+wRR2V36vpS5zJc1seyDocxtkhVObW2V/JBUFrKBbs5m/Ge9rgy+wK+ kFjvfc6BMx3IPwUQHlPcR+UZ4QZAZF7KPXOwElmJfqJyTg23wMMwklRpO/KGtaCojX7p GY9T0L0+T5aaqXX+T/LeTlgQnwoeK86SSb8IH8JkKM/duKO6XJT14w5AoTyCUXiYP5Jt yVUAhJB1kUMKzBpBvPABaksGTagGXpni6vSm3dgHhqkqSnnog+o1JAePeV/bwWTzqhVp SXBg== X-Gm-Message-State: AOAM5318wRjjYPit+Vtgkdd5fZUqlZRV4gcI9z8+1S07BfvJpBRounGD 0VbrCumkbRerdS74+nEQUX8J8T4SI6r6bIk/O5w= X-Google-Smtp-Source: ABdhPJytff5zNDQnBu6VlH0qQWBF9a3O/oyshkL6SKMrhhhCZ2SNacj88Ei7KGJM8+QR34SLC3OhJm+AJOaiChGf70k= X-Received: by 2002:a17:906:72d1:: with SMTP id m17mr22332230ejl.118.1615800182243; Mon, 15 Mar 2021 02:23:02 -0700 (PDT) MIME-Version: 1.0 References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com> <7926CAF0-69E7-415D-B635-B7C004EC838A@gmail.com> <755065BE2A0B4B508DD3A262B2A83801@DESKTOP0OKG1VA> In-Reply-To: <755065BE2A0B4B508DD3A262B2A83801@DESKTOP0OKG1VA> From: Richard Biener Date: Mon, 15 Mar 2021 10:22:51 +0100 Message-ID: Subject: Re: negative indexes To: Paul Edwards , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 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: Mon, 15 Mar 2021 09:23:04 -0000 On Sun, Mar 14, 2021 at 3:20 PM Paul Edwards wrote: > > Thanks Richard. > > Based on what you said I made this change: > > C:\devel\gcc\gcc\config\i370>cvs diff > cvs diff: Diffing . > Index: i370.h > =================================================================== > RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v > retrieving revision 1.51 > diff -r1.51 i370.h > 1156c1156 > < #define Pmode SImode > --- > > #define Pmode DImode > > and I was really excited to see if it fixed the problem, but > unfortunately the generated code is exactly the same. > > I looked further at the gcc source code but I don't really > know what I'm doing. Do you have any further hints? The above is likely not enough. Give it was SImode (I expected DImode) the backend is likely lying to the middle-end in a lot more places and maybe not set up to deal with 64bit address registers at all. > Thanks. Paul. > > > > > -----Original Message----- > From: Richard Biener > Sent: Monday, March 15, 2021 12:37 AM > To: Paul Edwards ; gcc@gcc.gnu.org > Subject: Re: negative indexes > > On March 14, 2021 9:12:01 AM GMT+01:00, Paul Edwards > wrote: > >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. > > And that's exactly what I said. Pmode is DImode but ptr_mode is SImode. > > > > >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. >