Re: gcc 3.2.3 x64 negative indexes

Problem solved. I didn't have this: #define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "unsigned int") because I wasn't including x86_64.h. This is the first time I have attempted to go to 64-bit pointers so I wasn't aware this even existed. So here it is doing Win64 ABI: D:\devel\gcc\gc

Re: gcc 3.2.3 x64 negative indexes

y shown correct x64 code being generated by gcc 3.2.3. Maybe they used an emulator or something. And I already have it running myself - with small modifications for MSABI - on Windows 10 64-bit - for my pdptest test program. The only thing not working for me at the moment that I know about is negati

Re: gcc 3.2.3 x64 negative indexes

It appears that this is not an issue that this version of GCC is architected to be able to solve. The first 64-bit PC processor, the AMD opteron series, was launched on April 22, 2003. GCC 3.2.3 was released on April 25, 2003. "*Opteron* is AMD

Re: gcc 3.2.3 x64 negative indexes

I have it down to a deliberate conversion from signed to unsigned: temp.txt: bbb piss ccc 32 32 temp.txt: bbb piss ccc2 0 1 temp.txt: bbb piss ddd -2 temp.txt: bbb - in convert temp.txt: bbb - converting to integer temp.txt: bbb y stage1 temp.txt: bbb y stage2 temp.txt: bbb y outprec thing, inprec

Re: gcc 3.2.3 x64 negative indexes

Oh - I switched to -2 to make debugging easier: D:\devel\gcc\gcc>type foo.c int foo(char *in) { return in[-2]; } D:\devel\gcc\gcc> Note that my flavor of gcc 3.2.3 can be found in gcc-stage*.zip in custom.zip at http://pdos.org On Sat, 10 Feb 2024 at 05:34, Paul Edwards wrote: > On Wed, 7

Re: gcc 3.2.3 x64 negative indexes

On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek wrote: On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote: >> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code: > Don't, gcc 3.2.3 is not supported for more than 20 years already. And the i370 target hasn't been s

Re: gcc 3.2.3 x64 negative indexes

On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote: > I am using a slightly modified gcc 3.2.3 for x86_64 and for this code: Don't, gcc 3.2.3 is not supported for more than 20 years already. > int fff(char *x) > { > return (x[-1]); > } > > > It is generating: > > .globl fff >

gcc 3.2.3 x64 negative indexes

Hi. I am using a slightly modified gcc 3.2.3 for x86_64 and for this code: int fff(char *x) { return (x[-1]); } It is generating: .globl fff fff: .LFB2: movl$4294967295, %eax movsbl (%rax,%rcx),%eax ret My understanding is that that move of -1 into eax does NOT s

Re: negative indexes

es 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 > >

Re: negative indexes

inal 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

Re: negative indexes

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 integ

Re: negative indexes

eally 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:

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

negative indexes

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 IC15,0(2,3) * Function foo epilogue See that (2,3) - that is adding both R2 + R3. R3 is

i370 - negative indexes

n R2 as an index. This works fine in AM24 and AM31 environments, but fails for AM64 where an address above 4 GiB is computed. Such code is very rare, so I would like to just have a rule that the index must always be a positive value, and for negative indexes like the above, different code is ge