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 278FC3858D1E; Sun, 19 May 2024 13:46:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 278FC3858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1716126418;
	bh=IW1/wTttmKQkk55GW6arBO70QY490gNIbyuTLIlGqBw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Nh7XbjxAfvpUhY2riZSjB5mrtpms/zzGof8JWJB6zEdeJllKu76gXEQzvsvoH357B
	 GNAZdW1ezL2j9KZsOp+ZwFz0HO5iL7Gg/vA43TQd6eoRLcs6XXdxJpFHENf+ypVHID
	 4vG7X/p4afIT+cfbdHE2p4W8R7NDF3pb7nMad1Jo=
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails
 with 'unaligned opcodes detected in executable segment'
Date: Sun, 19 May 2024 13:46:57 +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: 14.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo 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-115148-4-o5kDgR5waN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-115148-4@http.gcc.gnu.org/bugzilla/>
References: <bug-115148-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=3D115148

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> Created attachment 58244 [details]
> Preprocessed source from building read-vorbis.c with gcc-14 and -fverbose=
-asm
>=20
> (In reply to Oleg Endo from comment #3)
> > Can you please try to compile with -fverbose-asm .... maybe it will giv=
e a
> > first hint as to where the problematic code comes from.
>=20
> Done. See attached pr115148-preprocessed-source-verbose.tgz.

Thanks!

I was able to reproduce it myself rather easily with my limited setup.
The issue seems to be with the function 'barrier_align' in sh.cc which
determines the alignment following the data table that is emitted in the co=
de.

The following hunk seems to fix the ".align 1" following the short byte tab=
le

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index ef3c2e6791d..01349328171 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -5755,7 +5755,7 @@ barrier_align (rtx_insn *barrier_or_label)
       return ((optimize_size
               || ((unsigned) XVECLEN (pat, 1) * GET_MODE_SIZE (GET_MODE (p=
at))
                   <=3D (unsigned) 1 << (CACHE_LOG - 2)))
-             ? 1 : align_jumps.levels[0].log);
+             ? 2 : align_jumps.levels[0].log);
     }

   rtx_insn *next =3D next_active_insn (barrier_or_label);


However, I haven't checked for any advert side effects.


The line was modified last time in commit
e1fab8ba2337fd3bdd9c7112fae22d7ab001c2eb by myself, as part of the SH5 remo=
val.

-             ? 1 << TARGET_SHMEDIA : align_jumps_log);
+             ? 1 : align_jumps_log)

Before that, TARGET_SHMEDIA used to be defined as follows in sh.h:

#define TARGET_SHMEDIA (TARGET_SH5 && ! TARGET_SH1)

So for anything non-SH5 it should have evaluated to "0", which would produc=
e "1
<< 0" which is "1" for the problematic line above.

Maybe it's just a latent bug that got exposed by some other SH independent
basic block rearrangement optimizations.


Can you please attach the .s file when compiled with GCC 11, just for
comparison/reference.=