https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |middle-end
--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Just an FYI: I worked on a private port of gcc-14/15 to an old processor
> last year, and having <target>_frame_pointer_required switching from
> returning false to returning true during the compilation of a function
> resulted in wrong code.
OK, thanks for the insight. Yes, commit 2971ff looks questionable to me:
[LRA]: Check and update frame to stack pointer elimination after stack slot
allocation
Avr is an interesting target which does not use stack pointer to
address stack slots. The elimination of stack pointer to frame pointer
is impossible if there are stack slots. During LRA works, the
stack slots can be allocated and used and the elimination can be done
anymore. The situation can be complicated even more if some pseudos
were allocated to the frame pointer.
I fail to see how such an important decision as using the frame pointer can be
safely changed after the frame has been laid out; this may work for AVR but
probably not for most other targets.
