From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id A94BF385771B for ; Mon, 15 May 2023 21:09:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A94BF385771B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 5F30292009C; Mon, 15 May 2023 23:09:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 4FCB792009B; Mon, 15 May 2023 22:09:12 +0100 (BST) Date: Mon, 15 May 2023 22:09:12 +0100 (BST) From: "Maciej W. Rozycki" To: Segher Boessenkool cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Turn on LRA on all targets In-Reply-To: <20230423203328.GL19790@gate.crashing.org> Message-ID: References: <283c45ca085ced958cbce6e64331252c83a5899f.1682268126.git.segher@kernel.crashing.org> <20230423203328.GL19790@gate.crashing.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, 23 Apr 2023, Segher Boessenkool wrote: > > There are extra ICEs in regression testing and code quality is poor; cf. > > . > > Do you have something you can show for this? Maybe in a PR? I have filed no PRs as I didn't assess the collateral damage at the time I looked at it. I only ran regression-testing with `-mlra' shortly after I completed MODE_CC conversion and added the option, to see what lies beyond. And I only added `-mlra' and made minimal changes to make the compiler build again just to make it easier to proceed towards LRA. > And, are the ICEs in the generic code, or something vax-specific? At least some were in generic code, e.g.: during RTL pass: combine .../gcc/testsuite/gcc.c-torture/compile/pr101562.c: In function 'foo': .../gcc/testsuite/gcc.c-torture/compile/pr101562.c:12:1: internal compiler error: in insert, at wide-int.cc:682 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. compiler exited with status 1 FAIL: gcc.c-torture/compile/pr101562.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/pr101562.c -O1 (test for excess errors) (coming from `gcc_checking_assert (precision >= width)'), or: In file included from .../gcc/testsuite/g++.dg/modules/xtreme-header-2.h:10, from .../gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H:4: .../vax-netbsdelf/libstdc++-v3/include/regex:42: internal compiler error: in set_filename, at cp/module.cc:19134 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. compiler exited with status 1 FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors) (from `gcc_checking_assert (!filename)'). As I say, I did not assess this at all back then and the logs are dated Nov 2021 (I had to chase them). Also I'm not going to dedicate any time now to switch the VAX backend to LRA, because old reload continues working while we have a non-functional exception unwinder that never ever worked, as I have recently discovered, which breaks lots of C++ code, including in particular native VAX/NetBSD GDB and `gdbserver' (my newly-ported implementation of), which is a bit of a problem (native VAX/NetBSD GCC has been spared owing to the decision not to use exceptions). And fixing the unwinder is going to be a major effort due to how the VAX CALLS machine instruction works and the stack frame has been consequently structured; it is unlike any other ELF target, and even if it can be expressed in DWARF terms (which I'm not entirely sure about), it is going to require a dedicated handler like with ARM or IA64. I may choose to implement a non-DWARF unwinder instead, as the VAX stack frame is always fully described by the hardware and there is never ever a need for debug information to be able to decode any VAX stack frame (the RET machine instruction uses the stack frame information to restore the previous PC, FP, SP, AP and any static registers saved by CALLS). So implementing a working exception unwinder has to take precedence over LRA and I do hope to complete it during this release cycle, but I may not have any time left for LRA. Please keep this in mind with any plans to drop old reload. I'll highly appreciate that and I do keep LRA on my radar as the next item to address after the unwinder, by any means it's not been lost. Maciej