[Bug target/115148] New: [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[Bug target/115148] New: [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 115148
           Summary: [SH] [12/13/14 Regression]: libcanberra fails with
                    'unaligned opcodes detected in executable segment'
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: olegendo at gcc dot gnu.org
  Target Milestone: ---
            Target: sh*-*-*

Since gcc 12, building libcanberra on sh4 fails with:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$

This goes away when reducing the optimization to -O1:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O1
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$

or switching to gcc 11:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-11 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$

This might be related to PR101952. I'll try to isolate the offending
optimization flag now. Will also attach the preprocessed source shortly.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 58234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58234&action=edit
Preprocessed source from building read-vorbis.c with gcc-14

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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'

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-19
     Ever confirmed|0                           |1

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
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:
        braf    r1
        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'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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'

[olegendo at gcc dot gnu.org]

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.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #6 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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'

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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'

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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'

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(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'

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #12 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(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 <vmakarov@redhat.com>
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'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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'

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com

--- Comment #14 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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] [12/13/14/15 Regression][SH]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, ra
            Summary|[SH] [12/13/14 Regression]: |[12/13/14/15
                   |libcanberra fails with      |Regression][SH]:
                   |'unaligned opcodes detected |libcanberra fails with
                   |in executable segment'      |'unaligned opcodes detected
                   |                            |in executable segment'
   Target Milestone|---                         |12.4

[Bug target/115148] [12/13/14/15 Regression][SH]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #15 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 58258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58258&action=edit
Diff of generated assembly without and with changes from PR99531

I have generated a diff that shows the difference in the generated assembly
without and with the patch a7acb6dca941db2b1c135107dac3a34a20650d5c.

[Bug target/115148] [12/13/14/15 Regression][SH]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #15)
> Created attachment 58258 [details]
> Diff of generated assembly without and with changes from PR99531
> 
> I have generated a diff that shows the difference in the generated assembly
> without and with the patch a7acb6dca941db2b1c135107dac3a34a20650d5c.

That's great, thanks a lot!

This is the problematic hunks, which causes the wrong code alignment:

.LVL108:
        bt/s    .L178           !
        mov     #-1,r0  !, <retval>
@@ -1832,36 +1830,39 @@
        .byte   .L215-.L190
        .byte   .L181-.L190
 .LVL109:
-       .align 1
-.L192:
 .LBE111:
 .LBE110:
        .loc 1 234 9
        .loc 1 234 14
+       .align 1
+.L287:
+       .align 1
+.L288:

[Bug target/115148] [12/13/14/15 Regression][SH]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.4                        |12.5

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.4 is being released, retargeting bugs to GCC 12.5.