[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666

--- Comment #8 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #7)
> Thank you for your interest in the MMIX port.
> 
> (In reply to Wilco from comment #3)
> > (In reply to Sergei Trofimovich from comment #1)
> > 
> > >  #define MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS			\
> > >   (flag_exceptions						\
> > >    && ((reload_completed && df_regs_ever_live_p (MMIX_rJ_REGNUM))	\
> > >  || !leaf_function_p ())) /// <- here
> > 
> > 
> > Yes that looks like a bug. leaf_function_p cannot be called on a sequence as
> > it will incorrectly return true on non-leaf functions. So
> > MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS will randomly change its result if
> > called again later. starting_frame_offset should however return a fixed
> > value, so the reload_completed part also looks wrong.
> 
> Kindly refer to the comment above that macro:
> 
> /* We have no means to tell DWARF 2 about the register stack, so we need
>    to store the return address on the stack if an exception can get into
>    this function.  FIXME: Narrow condition.  Before any whole-function
>    analysis, df_regs_ever_live_p () isn't initialized.  We know it's
> up-to-date
>    after reload_completed; it may contain incorrect information some time
>    before that.  Within a RTL sequence (after a call to start_sequence,
>    such as in RTL expanders), leaf_function_p doesn't see all insns
>    (perhaps any insn).  But regs_ever_live is up-to-date when
>    leaf_function_p () isn't, so we "or" them together to get accurate
>    information.  FIXME: Some tweak to leaf_function_p might be
>    preferable.  */
> 
> So, it looks like the time has come for "some tweak to leaf_function_p",
> or...some other tweak.  Yes, this was a brittle solution and someone saw fit
> to pull the rug.  Maybe I'll have to compute the starting frame offset some
> other way.

I don't think that comment is accurate. The failure happens in cfgexpand before
any RTL has been generated, so leaf_function_p must not be called this early.
If starting_frame_offset doesn't remain constant things can go badly wrong.

The easiest fix is to always allocate an extra stack slot with exceptions and
then avoid generating extra code in the prolog/epilog if it happens to be a
leaf function.