Re: s390 port

2021-09-03 Thread Ulrich Weigand via Gcc
"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 naturally

Re: s390 port

2021-09-03 Thread Ulrich Weigand via Gcc
"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

Re: s390 port

2021-09-02 Thread Ulrich Weigand via Gcc
"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 a

Re: s390 port

2021-09-02 Thread Ulrich Weigand via Gcc
"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, w

Re: s390 port

2021-09-02 Thread Ulrich Weigand via Gcc
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 wo

Re: s390 port

2021-09-02 Thread Ulrich Weigand via Gcc
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 w

Re: Issue with pointer types marked with scalar_storage_order

2021-05-07 Thread Ulrich Weigand via Gcc
On Thu, May 06, 2021 at 04:07:52PM +0200, Eric Botcazou wrote: > > On the other hand, even the name of the attribute specifically > > refers to *scalar* types, and the C standard does classsify > > pointer types amongst the scalar type. So maybe this was > > originally intended? > > I don't think

Issue with pointer types marked with scalar_storage_order

2021-05-06 Thread Ulrich Weigand via Gcc
Hello, for a few years now, GCC has supported the scalar_storage_order attribute (and pragma) that allows specifying the storage order (endianness) of structures. This affects both the code GCC generates to access variables declared using the attribute, and also the debug info: GCC emits the DW_A