https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- 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
>
> (In reply to Oleg Endo from comment #3)
> > Can you please try to compile with -fverbose-asm .... maybe it will give a
> > first hint as to where the problematic code comes from.
>
> 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 code.
The following hunk seems to fix the ".align 1" following the short byte table
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 (pat))
<= (unsigned) 1 << (CACHE_LOG - 2)))
- ? 1 : align_jumps.levels[0].log);
+ ? 2 : align_jumps.levels[0].log);
}
rtx_insn *next = 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 removal.
- ? 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 produce "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.
