RE: [0/7] Type promotion pass and elimination of zext/sext

["Wilco Dijkstra" <wdijkstr@arm.com>]

> pinskia@gmail.com wrote:
> > On Sep 7, 2015, at 7:22 PM, Kugan <kugan.vivekanandarajah@linaro.org> wrote:
> >
> >
> >
> > On 07/09/15 20:46, Wilco Dijkstra wrote:
> >>> Kugan wrote:
> >>> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with
> >>> -O3 -g Error: unaligned opcodes detected in executable segment. It works
> >>> fine if I remove the -g. I am looking into it and needs to be fixed as well.
> >>
> >> This is a known assembler bug I found a while back, Renlin is looking into it.
> >> Basically when debug tables are inserted at the end of a code section the
> >> assembler doesn't align to the alignment required by the debug tables.
> >
> > This is precisely what seems to be happening. Renlin, could you please
> > let me know when you have a patch (even if it is a prototype or a hack).
> 
> 
> I had noticed that but I read through the assembler code and it sounded very much like it was
> a designed this way and that the compiler was not supposed to emit assembly like this and fix
> up the alignment.

No, the bug is introduced solely by the assembler - there is no way to avoid it as you can't expect
users to align the end of the code section to an unspecified debug alignment (which could
potentially vary depending on the generated debug info). The assembler aligns unaligned instructions
without a warning, and doesn't require the section size to be a multiple of the section alignment,
ie. the design is that the assembler can deal with any alignment.

Wilco