https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #35 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Terry Guo from comment #31)
> (In reply to Uroš Bizjak from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > > Let's ask Jakub about asan, if it is possible to move generation of the
> > > > call
> > > > after the function is already expanded to RTL.
> > >
> > > I'm afraid no.
> >
> > Hm...
> >
> > ... maybe we could go with following patch:
> >
> > + if (SUPPORTS_STACK_ALIGNMENT)
> > + {
> > + if (preferred_stack_boundary > crtl->stack_alignment_estimated)
> > + crtl->stack_alignment_estimated = preferred_stack_boundary;
> > + if (preferred_stack_boundary > crtl->stack_alignment_needed)
> > + crtl->stack_alignment_needed = preferred_stack_boundary;
> > + }
> >
> > This means that for functions, emitted through emit_library_call, stack
> > won't be realigned. This would cure the assert (and would follow a bit more
> > expand_stack_alignment from cfgrtl.c).
>
> I have same thought. I will test this one.
Actually, we can use crtl->stack_realign_processed to delay DRAP generation.
The condition in the patch should be changed to:
crtl->stack_realign_needed
= INCOMING_STACK_BOUNDARY < crtl->stack_alignment_estimated;
crtl->stack_realign_tried = crtl->stack_realign_needed;
---> if (crtl->stack_realign_processed && crtl->drap_reg == NULL_RTX)
{
rtx drap_rtx = targetm.calls.get_drap_rtx ();
Can you please test this change? The testcase from Comment #23 does not fail
for me.
