https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jgreenhalgh at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #12 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
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.
