From patchwork Thu Aug 22 10:31:35 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Paul Adrian Glaubitz X-Patchwork-Id: 1975425 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=fu-berlin.de header.i=@fu-berlin.de header.a=rsa-sha256 header.s=fub01 header.b=P0dWqjqk; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WqKJK4M7Qz1yYZ for ; Thu, 22 Aug 2024 20:32:00 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 219443845149 for ; Thu, 22 Aug 2024 10:31:58 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by sourceware.org (Postfix) with ESMTPS id F13C43858283; Thu, 22 Aug 2024 10:31:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F13C43858283 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=physik.fu-berlin.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zedat.fu-berlin.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F13C43858283 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=130.133.4.66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724322700; cv=none; b=bTIBvP6WRQyd8F8wNK8A3c9srOPKAV3aBSm24Ux9gdBaMckRH2r35mSjceT26hSzfk5fJvME7A9jLG8zxS4QGtt9QithYfsOLUBOz+EjW7GWUF30cKQn3TeZsQam+UeClkVnKuCA0ucy5IQvdad/++lJxkcQjgL4f/o1NFt+Tug= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724322700; c=relaxed/simple; bh=0+4y2/lenOkbzj8XptjyT8wSq00xGYrr4j1GqMmPHe8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=Lk71e0eslOfBO9cXW4P7M/rBmvr1Z38uoostPcRSqP2cC9/Gkmzloemj11AvE2TlhbsgHs/+pByYgQq26nKUjEL2/aXiy5boEz0+xpMHh1mWa2rH5dDV9OcQfSZMfgjZbefIHwnIzB3RO+yZ+W1Zs7cD59O98M1hKMSCsw7qCyA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fu-berlin.de; s=fub01; h=MIME-Version:Content-Transfer-Encoding: Content-Type:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=evvRThaXJtB2Mkx/x/pH9oSqngju9PYZZTdwaa1c8UQ=; t=1724322698; x=1724927498; b=P0dWqjqkwJzAMEHrr3OdbqVDw6oFabohtL1jb+DTf5zUAotLM+UWteo/fv+gxNySRSRzlntE1Tw KunRs/hVocUod0fOLXLG4nNpphIkuuVcXd/+uPbfNG7eVzIYLXLwdVCy+oK4w9B0y2j1Nele+cwpr HV9GlUxyNKiJ6SiYn9Rw/+PZ2Pz1VVsEXjxpM05FyHJnCEd8HR9hVqlOJy0iDje5ajNVrITMmjIx5 dG4qCiylDnxOX4VgM9c5Q+ZO0/gyTWlrnCH6PA84nWxUaGssdSdjOyAq4pzOvGhlxMrzd1fZPFd2p OGzvljJI5PUpJDKazXKIe3GbEJioGU8CpatQ==; Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.98) with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1sh56N-00000001OQq-4AfQ; Thu, 22 Aug 2024 12:31:36 +0200 Received: from p5b13a2bf.dip0.t-ipconnect.de ([91.19.162.191] helo=[192.168.178.20]) by inpost2.zedat.fu-berlin.de (Exim 4.98) with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1sh56N-00000003KTO-3IvP; Thu, 22 Aug 2024 12:31:35 +0200 Message-ID: <1492f7fed6cea211a174ad171f43cb0561eb1a37.camel@physik.fu-berlin.de> Subject: RFH: Debugging GCC segfault with LRA-enabled SH backend From: John Paul Adrian Glaubitz To: gcc-patches Cc: Oleg Endo , kkojima@gcc.gnu.org, Sam James , Falco Girgis Date: Thu, 22 Aug 2024 12:31:35 +0200 User-Agent: Evolution 3.52.4 MIME-Version: 1.0 X-Original-Sender: glaubitz@physik.fu-berlin.de X-Originating-IP: 91.19.162.191 X-ZEDAT-Hint: PO X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org (Please CC me in the replies, I am not subscribed to the list) Hi, I am currently trying to switch the SH backend to use the LRA register allocater by default with the help of patches by Oleg and Kaz (CC'ed) to address various issues when using LRA by default. The patches can all be found in the corresponding Bugzilla report [1]. Currently, I have applied the following patches from the bug report: - 58832 - 58833 - 58883 - 58905 plus the following change to enable LRA by default: Thus, I have now run out of ideas (as I'm not really a compiler expert). Does anyone else have any other suggestions? Thanks, Adrian PS: Would be great if we could upstream Linux SH native GDB support from [2] as well, in case any binutils-gdb maintainer is reading here. > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 > [2] https://github.com/glaubitz/binutils-gdb/tree/linux-sh diff --git a/gcc/config/sh/sh.opt b/gcc/config/sh/sh.opt index c44cfe70cb1..718dfb744ff 100644 --- a/gcc/config/sh/sh.opt +++ b/gcc/config/sh/sh.opt @@ -299,5 +299,5 @@ Target Var(TARGET_FSRRA) Enable the use of the fsrra instruction. mlra -Target Var(sh_lra_flag) Init(0) Save +Target Var(sh_lra_flag) Init(1) Save Use LRA instead of reload (transitional). With these changes applied, I have configured and built GCC from Git as follows: # ../configure --disable-multilib --enable-multiarch --enable-bootstrap --enable-languages=c,c++ # make -j32 which fails on QEMU with a segmentation fault: /srv/glaubitz/gcc/build/./gcc/xgcc -B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/ \ -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem /usr/local/sh4-unknown-linux-gnu/include -isystem \ /usr/local/sh4-unknown-linux-gnu/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC \ -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -isystem ./include -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2 \ -fbuilding-libgcc -fno-stack-protector -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -I. -I. \ -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include \ -DHAVE_CC_TLS -o _paritysi2.o -MT _paritysi2.o -MD -MP -MF _paritysi2.dep -DL_paritysi2 \ -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS during GIMPLE pass: waccess ../../../libgcc/libgcc2.c: In function '__muldi3': ../../../libgcc/libgcc2.c:538:1: internal compiler error: Segmentation fault 538 | } | ^ during GIMPLE pass: waccess This is reproducible on real hardware (Renesas SH-7785LCR, Linux 6.5.0), so it's not an emulation issue. I have tried to debug this issue with my Linux-SH-enabled GDB fork [2] and got the following backtrace: (gdb) bt #0 0x0109fee4 in wi::add_large(long long*, long long const*, unsigned int, long long const*, unsigned int, unsigned int, signop, wi::overflow_type*) () #1 0x00bdbc10 in access_ref::add_offset(generic_wide_int > const&, generic_wide_int > const&) () #2 0x00bdd0e8 in compute_objsize_r(tree_node*, gimple*, bool, int, access_ref*, ssa_name_limit_t&, pointer_query*) () #3 0x00000000 in ?? () (gdb) display/i $pc 1: x/i $pc => 0x109fee4 <_ZN2wi9add_largeEPxPKxjS2_jj6signopPNS_13overflow_typeE+84>: mov.l @r2,r3 (gdb) x/wx $r2 0x7c07eaa0: Cannot access memory at address 0x7c07eaa0 (gdb) I have also tried disabling late combine by SH by default, but that didn't help: diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc index 280588268ae..dca27893536 100644 --- a/gcc/config/sh/sh.cc +++ b/gcc/config/sh/sh.cc @@ -1047,6 +1047,9 @@ sh_override_options_after_change (void) str_align_functions = r; } } + + if (!OPTION_SET_P (flag_late_combine_instructions)) + flag_late_combine_instructions = 0; } ^L /* Print the operand address in x to the stream. */