https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877
Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #46574|0 |1
is obsolete| |
--- Comment #18 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
Created attachment 46577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46577&action=edit
patch for aligned stack - but clamping max alignment at
MAX_SUPPORTED_STACK_ALIGNMENT
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
> > --- Comment #15 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
> > Created attachment 46574 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46574&action=edit
> > patch for the case that the stack is sufficiently aligned
> [...]
> > I have attached a patch to preserve the alignment of the passed type for the
> > case that the stack is already sufficiently aligned.
>
> This patch breaks sparc-sun-solaris2.11 bootstrap with an ICE while
> compiling stage2 function.c:
>
> during RTL pass: expand
> /vol/gcc/src/hg/trunk/local/gcc/function.c: In function 'void
> assign_parm_find_data_types(assign_parm_data_all*, tree,
> assign_parm_data_one*)':
> /vol/gcc/src/hg/trunk/local/gcc/function.c:2426:49: internal compiler error:
This location doesn't make much sense to me. Maybe some artefact from
optimized compilation and register windows?
> in assign_stack_temp_for_type, at function.c:880
> 2426 | else if (targetm.calls.strict_argument_naming (all->args_so_far))
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
> 0x11bc22f assign_stack_temp_for_type(machine_mode, poly_int<1u, long long>,
> tree_node*)
> /vol/gcc/src/hg/trunk/local/gcc/function.c:878
> 0x11bc963 assign_temp(tree_node*, int, int)
This looks like the modified assert there has triggered. It'd be interesting
to know why - i.e. what variable does want more alignment than
MAX_SUPPORTED_STACK_ALIGNMENT - during bootstrap? Or is this a BLKmode
variable with less alignment than BIGGEST_ALIGNMENT?
User code could specify silly alignments which we couldn't provide with
ordinary
allocation (using a fixed offset from sp/fp) and which could also blow up the
frame size too much if we tried, so it makes sense to clamp the alignment to
MAX_SUPPORTED_STACK_ALIGNMENT in get_stack_local_alignment.
The other side is that the code in assign_stack_temp_for_type seems to require
BIGGEST_ALIGNMENT for BLKmode; I'm not sure about assign_stack_local_1
slots. It seems a bit wasteful, but trying to reduce waste of space in the
stack frame is really a different issue, so I also modified the patch to use
at least BIGGEST_ALIGNMENT for BLKmode so that it's (bug-?)compatible in that
aspect with the previous code - see attached modified patch.
