https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to James Greenhalgh from comment #12)
> I can still trigger this with a testcase using 16-bit floating-point types,
> and the tiny memory model:
>
> int
> main (__fp16 x)
> {
> __fp16 a = 6.5504e4;
> return (x <= a);
> }
>
> gcc foo.c -O3 -mcmodel=tiny -g
>
> /tmp/ccwJITmo.s: Assembler messages:
> /tmp/ccwJITmo.s: Error: unaligned opcodes detected in executable segment
>
> In this test case, a call to force_const_mem in ira adds a new 32-bit
> constant in the constant pool, but ultimately doesn't use it. That means
> that when we sweep patterns looking for which constant pool entries to emit,
> we don't mark the unused pattern created by ira, and it doesn't get emitted.
> But, that leaves us with inconsistent information between the offset we
> think we've got, and what we've actually emitted.
>
> Presumably IRA isn't the only pass at fault here. Anything which eliminates
> a reference to a constant pool entry can cause the constant pool offset
> information to become stale.
>
> Maybe force_const_mem shouldn't be updating the offset information at all,
> and we should only update that as we make the sweep looking for live pool
> entries? I guess the trouble there is that we don't record the mode of the
> mem in the constant_descriptor_rtx - but if we were to do that it looks like
> we might be able to defer calculating offset until when we actually emit the
> pool. rs6000 might need some changes, but a better interface for their uses
> of get_pool_size looks like it would be "pool_empty_p" anyway.
>
> I'm not sure of this code though, so I don't know if that would make for a
> clean design.
>
> If you think this needs to be a separate bug, feel free to reclose this and
> open a new one.
I do think a new bug should be opened.
