https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #7 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- 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.
