From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 791C3385842D for ; Thu, 2 Sep 2021 10:56:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 791C3385842D Received: by mail-pl1-x635.google.com with SMTP id q3so923008plx.4 for ; Thu, 02 Sep 2021 03:56:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:subject:date:mime-version :content-transfer-encoding:importance; bh=Tl+3jKIfq2R+/22MwZ7dznoOb79fA8mYgs/z2jnGX/Q=; b=Ffp4kRkousyzSZYQsW/kiKiqWxq5UNTObnDYfOnUo+9/ZsNlD/S3LRrVxnH+IWdHB4 80mbmkUvECKTfMruLsf4CbgwAxgVhY+KqHv5nip5GwLrWqBHhj4xmoPZ5E1EIevygf6R vGT9IpJ28d+zZQZVpZUUjrtPv7pVZMNRb78fgYt1Q6oM/9qUSa7IDs11UlFonKC3/m6F ucmOmFhE19Xdf67CkWZniKd1pFEWSua321XbB4/HrxGEd+Gz3B0Jh9yYWz6jdmPYjeuq 7X21LSTYs79WMpamkwoyYUZRJyfqH7kuRsZnatJI9eHI6cVIFyFVnqKf9cqZ1Yhr93YZ QWGA== X-Gm-Message-State: AOAM532o0RuchaRT59Uv8wUp7S+4tzh1ZmPu143f/TFiui/Z3AJaoM6h t0krtjkewp8ZxnV3ws+KxokiLt8HvjY= X-Google-Smtp-Source: ABdhPJzXm+74zYhcwxCIXtQF8seVOlL4yEK/j+p8atfBzfYqxPy18vmh/d0+bHF3tLdA/1aEw3jaww== X-Received: by 2002:a17:902:ab53:b0:12d:d95e:f651 with SMTP id ij19-20020a170902ab5300b0012dd95ef651mr2409565plb.53.1630580213456; Thu, 02 Sep 2021 03:56:53 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id q29sm2511051pgc.91.2021.09.02.03.56.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Sep 2021 03:56:52 -0700 (PDT) Message-ID: <515786DA9BE541A787FB2E1B4F4873C3@DESKTOP0OKG1VA> From: "Paul Edwards" To: "Ulrich Weigand" Cc: Subject: Re: s390 port Date: Thu, 2 Sep 2021 20:56:47 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 10:57:05 -0000 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 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.Weigand@de.ibm.com