= TREE_CONSTANT (ptrop) & TREE_CONSTANT (intop);
> return folded;
> }
>
>
>
> On Sat, 10 Feb 2024 at 05:38, Paul Edwards wrote:
>
>> Oh - I switched to -2 to make debugging easier:
>>
>> D:\devel\gcc\gcc>type foo.c
>> int foo(char *in)
>> {
>&
(replying to Joe Monk)
> 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.
Jakub has already shown correct
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:
>
>> O
t; 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.
&g
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 ha
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
I normally use gcc 3.2.3 to build executables that
work with msvcrt.dll, which has 32-bit int, long and ptr.
I tried changing long to 64 bits and the new compiler
encountered the following issue when attempting to
build itself. Documented and fixed below, unless
someone has a better fix. Note
I have a slightly modified gcc 3.2.3.
Source is available in gcc-stage* in custom.zip at http://pdos.org
Executables are available in customb.zip but everything that
is really needed is in pdos.zip
gccdos.txt has instructions to run windows.mak which
produces the gccx64.exe that I use, but has
88(,13)
>> L 15,=A(@@7)
>> BALR 14,15
>>
>>
>> @@LC32 EQU *
>> DCC'MEMTEST'
>> DCX'0'
>> @@LC33 EQU *
>> DCC'writing 4 bytes to address X''7FFE'''
>> DC X'15'
ressed in standard z/Arch, with "-m31".
Prove it on real hardware, not hercules. Hercules doesnt count.
Joe
On Wed, Sep 29, 2021 at 7:09 PM Paul Edwards via Gcc
wrote:
>* We have fait accompli now:
*>>* https://gcc.gnu.org/pipermail/gcc/2021-September/237456.html
<https://gcc
On Fri, 3 Sept 2021 at 20:12, Ulrich Weigand
wrote:
> "Paul Edwards" wrote on 03.09.2021 13:35:10:
> > > Specifically, if you try to run AMODE64 with Pmode equals
> > > SImode, the compiler will not be aware that the hardware
> > > uses the high 32 bits of base and index registers, and
> > >
Hi.
In certain places, the i370 target of GCC 3.2.3 will use a
base + index + displacement operand.
How can I add a constraint to say that the index must be
between 0 and 0x7fff?
I want to stop 0x from being generated when I have:
char *p
p[-1];
Thanks. Paul.
--
This email has
Hi Michael.
I have sort of (I used the i370 target of GCC 3.2.3 instead
of the s390 target) reproduced Jesus's work with z/PDOS
which can be obtained from here:
http://www.pdos.org/zpdos.zip
You can see that with standard Hercules 3.13:
18:02:24 Hercules Version 3.13
18:02:24 (c)Copyright
Hi Michael.
Thanks for picking up this issue. I have been working
with Jesus on this.
m31 is semantically the same as the m32 option.
The m31 option allows for 32 bit addressing and that is confusing since
the m31 option in S390 would mean 2 GiB space addressing
Indeed that's exactly what
Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
Prove it on real hardware, not hercules. Hercules doesnt count.
Real mainframe hardware is not easily accessible.
Hercules is the most convenient way
We have fait accompli now:
https://gcc.gnu.org/pipermail/gcc/2021-September/237456.html
Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
The above request is to add "-m32" as an alias for
"-m31", but
Hi Joe.
Thanks for your comments.
> It is unclear how this would even work.
> For instance, the LA instruction clears the top bit.
In AM64, LA does not clear any bits.
> Also, instructions like LPR, LNR,
These operate on data registers, not addresses,
and will continue to work unchanged.
>
> This is not in one single place, but spread throughout the
> compiler, both common code and back-end. I do not think it will
> be possible to get the compiler to generate correct code if
> you do not specify the address size correctly.
1. Is there any way to put a constraint on index
>> > Also, the compiler
>> > will assume the base + index (+ displacement) arithmetic
>> > will operate in 32 bits -- I'm pretty sure this is
>> > actually the root cause of your "negative index" problem.
>> Where is this logic please? Can I do a #if 0 or similar
>> to disable it?
> This is
> - AMODE64 means the native address size is 64 bits. This
> implies that Pmode has to be DImode, since Pmode tells
> the compiler what the native address size is.
> Specifically, if you try to run AMODE64 with Pmode equals
> SImode, the compiler will not be aware that the hardware
> uses
Hi Ulrich. Thanks for your detailed reply.
>> > Therefore again my question, what is the actual goal
>> > you want to achieve? I'm still not sure I understand
>> > that ...
>> I would like to know what is required to implement
>> “-m32” in the S/390 target. I realize that z/Arch
>> doesn’t have
Hi Ulrich.
Thanks a lot for your reply.
Could you give me an example of an instruction
generated by –m31 that is not expected to work
on an AM64 system?
E.g. the 32-bit
LR R2,R3
will definitely work on AM64.
So what specifically won’t work? How many different
things won’t work?
Thanks.
>> I just checked my copy of s390.md and I don’t see
>> LA being used for arithmetic.
> This would be the "*la_31" and "*la_31_and" patterns.
Sorry, I did a grep for “LA”, forgetting that
s390.md doesn’t use uppercase instructions.
> (Note that the addition is implicit in the use of
> the
Hi Ulrich.
I just checked my copy of s390.md and I don’t see
LA being used for arithmetic.
If your copy of s390.md is using LA for arithmetic
then would it be possible to have an option to
use a normal mathematics instruction instead of
LA?
Do you have any more examples besides LA being
used
Hi Ulrich.
Below is the output as text.
Thanks. Paul.
make all-recursive
make[1]: Entering directory '/home/robertapengelly/Desktop/UDOS'
Making all in kernel
make[2]: Entering directory '/home/robertapengelly/Desktop/UDOS/kernel'
depbase=`echo irq.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
Hi Ulrich.
Sorry for the necro - things happen slowly Down Under. :-)
Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos
(just a hobby, won't be big and professional like Linux)
We got the IPL process in place on ESA/390, and then
I
Actually, what I want is a processor with ECS,
EDS and EES, as new registers, and for GCC
to target that, supporting near, far and huge
code pointers and data pointers.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Tuesday, March 16, 2021 12:55 AM
To: GCC Development
Would it be possible for GCC to generate code
that reserves ESI and EDI as "extended segment"
registers to hold a source and destination
"extended segment" of any operation.
This will be the upper 32-bits of a 64-bit address.
When run on a normal 80386, such code will work
fine, and ESI and EDI
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
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
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
31 matches
Mail list logo
