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

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.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?