http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bernds at gcc dot gnu.org,
| |law at gcc dot gnu.org
AssignedTo|jakub at gcc dot gnu.org |unassigned at gcc dot
| |gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-25
15:40:22 UTC ---
Ugh, this is ugly.
The problem is that Bernd's changes conflict with the way
assign_stack_temp_for_type/combine_temp_slots works.
Both are now parallel lists of stack slot information, but they aren't aware of
each other.
So, when assign_stack_temp_for_type is called to allocate slot for 12 byte long
16 byte aligned slot (for fn7 return value), this internally calls
assign_stack_local (why we CEIL_ROUND the size to 16 in that case is something
I don't understand). assign_stack_local_1 sees the current frame offset is not
16 byte aligned, so it eats 8 bytes for alignment and 16 bytes for the actual
stack slot. assign_stack_local_1 then calls add_frame_space for the extra 8
bytes, so
that it can be used by something else later (by assign_stack_local_1) - this is
Bernd's new code.
But in assign_stack_temp_for_type it tracks the allocation in struct temp_slot,
and there it records the whole stack block including whatever padding had to be
made again (i.e. 24 bytes in this case).
If assign_stack_local called from here will actually return something from the
queued frame space slots, then frame_offset_old == frame_offset and thus it
will do really weird things, that is something that needs to be fixed too, but
is not something that happens in this case (I'd say if frame_offset_old ==
frame_offset and it wasn't BLKmode with size 0, then it should record as
size/full_size just the requested size and nothing else).
In this testcase afterwards assign_stack_temp_for_type is called for 20 byte
BLKmode requesting 16 byte alignment, and as this is -fno-strict-aliasing, it
chooses that it could share the temp slot with the above allocated one and as
its size/full_size was 24, it just uses it. Nothing informs the frame_space
list about this though and thus it will happily give that slot again during
reload.
