at location 0 is different (still contains
>> the IPL PSW!) from the memory at location x'8000'.
>>
>> Do you have any further objections, other than a logical
>> fallacy such as argumentum ad populum or argumentum ad
>> baculum, to oppose gcc having -m32 as
t 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.gnu.org/pipermail/gcc/2021-September/237456.html>
for
*>* "-m31", but I would like to add as a request for it to
*>* work with optimization on.
*>>* BFN. Paul.
*>>>>>* -Original Message-
*>* From: Paul Edwards
*>* Sent: Friday, September 3, 2021 11:12 PM
*>* To: Jakub Jelinek
*>* Cc: Ulr
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
> > >
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
to add "-m32" as an alias for
> "-m31", but I would like to add as a request for it to
> work with optimization on.
>
> BFN. Paul.
>
>
>
>
> -Original Message-
> From: Paul Edwards
> Sent: Friday, September 3, 2021 11:1
s an alias for
"-m31", but I would like to add as a request for it to
work with optimization on.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Friday, September 3, 2021 11:12 PM
To: Jakub Jelinek
Cc: Ulrich Weigand ; gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
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.
>
It is unclear how this would even work.
For instance, the LA instruction clears the top bit.
Also, instructions like LPR, LNR, BXLE, BXH all treat the value in the
register as signed, so the top bit is not available.
Joe
> 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
On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote:
> > 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
>> > 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
"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
> > will not necessarily keep them zero.
> The compiler
> - 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
"Paul Edwards" wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.
OK, that makes things clearer. This implies in particular:
- 4GB address space means you need to run in AMODE64
- AMODE64 means the native address size
On Sep 03 2021, Paul Edwards via Gcc wrote:
> The “legacy” environment of z/Linux etc would be 32-bit
> instead of 31-bit. IBM’s reputation will be restored. IBM
> will have the best architecture on the planet. Better than
> x64 because no mode switch is required shifting between
> 32-bit and
other way around. The compiler knows
> exactly how the LA instruction behaves in hardware,
> and will use the instruction whenever that behavior
> matches the semantics of (a part of) the program.
> Since the behavior of the instruction differs based
> on the addressing mode, the compil
"Paul Edwards" wrote on 02.09.2021 17:26:25:
> > 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
.
From: Ulrich Weigand
Sent: Friday, September 3, 2021 12:34 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the
at the addition is implicit in the use of
> the "address_operand" constraint.)
If it is an address we are talking about, then that LA
instruction is going to work perfectly fine in AM24,
AM31 and AM64, and in the AM64 case it is going
to be the equivalent of AM32, so maybe the s390
port cou
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to address computation, of course.
For example, GCC may use LA on -m31 to implement a
31-bit addition,
Hi Paul,
> 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.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)
> If your copy of s390.md is using LA for arithmetic
> then
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we
To: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to
ve] Error 1
make[1]: Leaving directory '/home/robertapengelly/Desktop/UDOS'
make: *** [Makefile:326: all] Error 2
-Original Message-
From: Paul Edwards
Sent: Thursday, September 2, 2021 6:15 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: s390 port
Hi Ulrich.
Sorry for the necro - th
I'm sceptical about is 370 architecture
support -- I don't quite see why this is still useful today (the s390
port does require at a minimum a S/390 G2 with the branch relative
instructions ... but those have been around for nearly 15 years).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86804
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86804
Bug ID: 86804
Summary: s390 port needs updating for CVE-2017-5753
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
28 matches
Mail list logo
