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$||'`;\
s390-linux-gcc -DHAVE_CONFIG_H -I. -I.. -ffreestanding -fno-stack-protector
-pipe -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings
-Wstrict-prototypes -Wmissing-declarations -Wdouble-promotion -Wredundant-decls
-Wnested-externs -Winline -Wconversion -fexec-charset=IBM-1047 -O2 -m31 -g
-MT irq.o -MD -MP -MF $depbase.Tpo -c -o irq.o irq.c &&\
mv -f $depbase.Tpo $depbase.Po
during RTL pass: reload
In file included from irq.c:3:
./panic.h: In function ‘kpanic’:
./panic.h:21:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
21 | }
| ^
0xce67fc lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:5091
0xcd2fa2 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2336
0xc8a2f9 do_reload
../../gcc/gcc/ira.c:5932
0xc8a2f9 execute
../../gcc/gcc/ira.c:6118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:418: irq.o] Error 1
make[2]: Leaving directory '/home/robertapengelly/Desktop/UDOS/kernel'
make[1]: *** [Makefile:406: all-recursive] 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 - 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 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 were able to use GCC 11 to
target S/390 and use the -m31 to generate 32-bit code,
run it under z/Arch as AM64, sort of making it the
equivalent of AM32. Really it is the equivalent of
AM-infinity, and there's the rub - GCC 11 is generating
negative indexes, which cause memory above 4 GiB
to be accessed (instead of wrapping at 2/4 GiB), which
of course fails.
Do you have any idea how to stop the S/390 target
from generating negative indexes? I thought the
solution might be to change the Pmode to DImode
even for non-TARGET64, but as you can see here:
http://www.pdos.org/gccfail.png
we got an internal compile error - maximum number
of generated reload insns per insn achieved (90).
I then tried changing the other SImode reference
(CASE_VECTOR_MODE) to DImode too, but that gave
the same internal error.
Here is what the failure looks like (see the large R4):
01:28:27 PSW=00042001 80000000 0000000000005870 INST=A73A0001 AHI 3,1
add_halfword_immediate
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579
R3=00000000000080B2
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C
RF=000000000001E4E4
01:28:27 PSW=00042001 80000000 0000000000005874 INST=42142FFF STC
1,4095(4,2) store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C
RF=000000000001E4E4
01:28:27 HHCCP014I CPU0000: Addressing exception CODE=0005 ILC=4
01:28:27 PSW=00042001 80000000 0000000000005878 INST=42142FFF STC
1,4095(4,2) store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C
RF=000000000001E4E4
01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 80000000
0000000000000444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown
Any idea what we can do?
Thanks. Paul.
-----Original Message-----
From: Ulrich Weigand
Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
In addition, that code has been ported to GCC 3.4.6, which is now
working as a cross-compiler at least. It's still some months away
from working natively though. It takes a lot of effort to convert
the Posix-expecting GCC compiler into C90 compliance. This has
been done though, in a way that has minimal code changes to the
GCC mainline.
You're referring to building GCC for a non-Posix *host*, right?
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?
Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
HLASM, isn't 370, isn't C90, isn't MVS. It may well be possible to
change all those things, and I suspect that in a few years from now
I may be sending another message asking what I need to do to get
all my changes to the s390 target into the s390 target. At that time,
I suspect there will be a lot of objection to "polluting" the s390 target
with all those "unnecessary" things.
Actually, I would really like to see the s390 target optionally support
the MVS ABI and HLASM assembler format, so I wouldn't have any objection
to patches that add these features ...
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more. If there are other problems related to MVS host
support, I suppose those would need to be fixed in common code anyway,
no matter whether the s390 or i370 back-ends are used.
The only point in your list 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 for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
