From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 58622385DDFD; Sat, 17 Aug 2024 02:54:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58622385DDFD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1723863284;
	bh=VpCzVudSF/nV6h26iwPMgunu8XL8PhwBiDUa9gy6ASU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=X/0K3nh4EHM0jmbWHKPSN1vf/DAt16Ye2ZbiQzoONthnE1cN/wWIDEj1vk8s/gkYt
	 QXS3CEhtrYCI2gVPvfg7Z3WmVDDWJRKoOUQUmk7UqOG6dMDo559e1V1uO+9E0toDS/
	 gfXTT8Lo1E+rgAcel5d5eAdnbhEpYdXNSeUzysvU=
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/55212] [SH] Switch to LRA
Date: Sat, 17 Aug 2024 02:54:40 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-55212-4-q7DlAlnWZc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55212-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55212-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D55212

--- Comment #174 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #169)
> I'll try running gcc testsuite with the sh-elf cross compiler on old sh-s=
im.
> There may not be much chance, but it might catch the wrong code bug.

The results w/wo -mlra are exactly the same on the patched compiler. For
example,

make check-gcc RUNTESTFLAGS=3D"execute.exp --target_board=3Dsh-sim/-m4"
make check-gcc RUNTESTFLAGS=3D"execute.exp --target_board=3Dsh-sim/-m4/-mlr=
a"

                =3D=3D=3D gcc Summary =3D=3D=3D

# of expected passes            23910
# of unexpected failures        96

The result for the unpatched trunk compiler with -m4 is same,  but with  -m4
for  the vanilla compiler 14.0.1 20240222 shows=20

# of unexpected failures        93

and 3 new failures on the current master compilers are

> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fno-use-linker-pl=
ugin -flto-partition=3Dnone  execution test

It doesn't look that this issue is the cause of the segfault.  This is a bad
sign, though.
Can the unpatched trunk gcc15 bootstrap with reverting enable -mlra by defa=
ult
patch in c#121 in the first place?  I assume that gcc14 can bootstrap
successfully with -mno-lra.

I'll look the above execution errors into more closely.

BTW, the patched (58832, 58833,58883,58905) gcc 14.0.1 20240222 has no abov=
e 3
FAILs for gcc.c-torture/execute/struct-ret-1.c and moreover -mlra fixes one
more case

PASS: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

which was failed even with unpatched 14.0.1.=