[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 Oleg Endo changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #14 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #13) > I can even confirm that reverting a7acb6dca941db2b1c135107dac3a34a20650d5c > (with some minor merge adjustments) on current git master fixes the problem > for me. Great. Thanks a lot! Vladimir, do you have any idea what could be going wrong here? It seems after your change in ira-costs.c, the emitted .align directive that is emitted in in sh.cc (barrier_align) gets moved around which results in wrongly aligned labels. It's difficult for me to imagine the connection of the two ...
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #13 from John Paul Adrian Glaubitz --- I can even confirm that reverting a7acb6dca941db2b1c135107dac3a34a20650d5c (with some minor merge adjustments) on current git master fixes the problem for me.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #12 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #11) > (In reply to John Paul Adrian Glaubitz from comment #10) > > > > Yes, definitely. Will take a little longer though as I need to fix my setup > > first. > > Thanks in advance. Wait for your update. OK, done. Bisect lead me to the following commit: commit a7acb6dca941db2b1c135107dac3a34a20650d5c Author: Vladimir N. Makarov Date: Mon Dec 13 13:48:12 2021 -0500 [PR99531] Modify pseudo class cost calculation when processing move involving the pseudo and a hard register Pseudo class calculated on the 1st iteration should not have a special treatment in cost calculation when processing move involving the pseudo and a hard register. gcc/ChangeLog: PR target/99531 * ira-costs.c (record_operand_costs): Do not take pseudo class calculated on the 1st iteration into account when processing move involving the pseudo and a hard register. gcc/testsuite/ChangeLog: PR target/99531 * gcc.target/i386/pr99531.c: New test. gcc/ira-costs.c | 22 +- gcc/testsuite/gcc.target/i386/pr99531.c | 7 +++ 2 files changed, 8 insertions(+), 21 deletions(-) create mode 100644 gcc/testsuite/gcc.target/i386/pr99531.c I have double-checked that this commit introduces the regression.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #8) > Adrian, if you have the means, can you bisect it to pinpoint the commit > where this error starts occuring? Yes, definitely. Will take a little longer though as I need to fix my setup first.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #11 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #10) > > Yes, definitely. Will take a little longer though as I need to fix my setup > first. Thanks in advance. Wait for your update.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #9 from Oleg Endo --- (In reply to Oleg Endo from comment #8) > > It looks like something dpulicates the ".align 1" directive after the byte > table and then also duplicates it. Perhaps the directive is treated wrongly > as an insn or something like that . Wanted to write: It looks like something duplicates the ".align 1" directive after the byte table and then also sinks it further down in the code between the other labels.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #8 from Oleg Endo --- (In reply to Oleg Endo from comment #7) > (In reply to Oleg Endo from comment #5) > > > > 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); > > > > > > Sorry, I forgot that ".align 1" actually means alignment on 2-byte boundary. > So that shouldn't be the issue there. But indeed, there is something going on with the placement of the .align directive after the short byte table. GCC 11: .L225: .long ov_read@PLT-(.LPCS29+2-.) .align 2 .L188: .byte .L214-.L189 .byte .L214-.L189 .byte .L197-.L189 .LVL111: .align 1 .L191: .LBE111: .LBE110: .loc 1 234 9 .loc 1 234 14 ! read-vorbis.c:234: ca_assert(v->size >= (off_t) n_read); GCC 13: .L225: .long ov_read@PLT-(.LPCS29+2-.) .align 2 .L187: .byte .L213-.L188 .byte .L213-.L188 .byte .L179-.L188 .LVL110: .LBE111: .LBE110: .loc 1 234 9 .loc 1 234 14 .align 1 .L285: .align 1 .L286: ! read-vorbis.c:234: ca_assert(v->size >= (off_t) n_read); This puts the labels LVL110, LBE111, LBE110 at the wrong odd byte alignment. Adding a '.align 1' manually after the byte table allows assembling the file without errors. It looks like something dpulicates the ".align 1" directive after the byte table and then also duplicates it. Perhaps the directive is treated wrongly as an insn or something like that . Adrian, if you have the means, can you bisect it to pinpoint the commit where this error starts occuring?
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #7 from Oleg Endo --- (In reply to Oleg Endo from comment #5) > > 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); > > Sorry, I forgot that ".align 1" actually means alignment on 2-byte boundary. So that shouldn't be the issue there.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #6 from John Paul Adrian Glaubitz --- Created attachment 58245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58245&action=edit Preprocessed source from building read-vorbis.c with gcc-11 and -fverbose-asm (In reply to Oleg Endo from comment #5)> > Can you please attach the .s file when compiled with GCC 11, just for > comparison/reference. Sure, see attached.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #5 from Oleg Endo --- (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.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #4 from John Paul Adrian Glaubitz --- Created attachment 58244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58244&action=edit 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.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-19 Ever confirmed|0 |1 --- Comment #3 from Oleg Endo --- In your attached libcanberra_la-read-vorbis.s I can spot the following suspicious code: .LBB70: .loc 1 44 9 is_stmt 0 mova.L52,r0 .LVL48: mov.b @(r0,r2),r1 extu.b r1,r1 .LVL49: brafr1 nop . .L82: .long ca_vorbis_get_nchannels@PLT-(.LPCS10+2-.) .L86: .long free@PLT-(.LPCS9+2-.) .L87: .long ov_clear@PLT-(.LPCS11+2-.) .align 2 .L52: .byte .L54-.L53 .byte .L54-.L53 .byte .L51-.L53 .align 1 (1) .L54: .LBE70: .LBE72: (2) .loc 1 61 24 bra .L50 mov #-7,r9 In (1) a lookup table of 3 bytes is emitted. Because of the following ".align 1" directive, the following code at (2) will be misaligned. Can you please try to compile with -fverbose-asm maybe it will give a first hint as to where the problematic code comes from.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #2 from John Paul Adrian Glaubitz --- It will succeed, if any of the following optimizations are removed: -fcrossjumping -finline-functions -finline-small-functions -freorder-blocks-algorithm=stc -ftree-pre -ftree-tail-merge -ftree-vrp Consequently, it always fails when these flags are present at the same time.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 58234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58234&action=edit Preprocessed source from building read-vorbis.c with gcc-14
