https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432
--- Comment #28 from Neal Frager <neal.frager at amd dot com> --- (In reply to Gopi Kumar Bulusu from comment #27) > It is a structured process of analysis > > check gcc/config/microblaze/microblaze.cc > > MicroBlaze stack frames look like: > > +-----------------------+ > | | > | arguments for called | > | subroutines | > | (optional) | > | | > +-----------------------+ > | Link register | > low FP,SP->| | > memory +-----------------------+ > > > Based on the above description, there is nothing wrong with compiler using > the caller's stack frame to save r5 > > In fact when one looks at the "regression" - the first reaction is that it > looks like a compiler defect, however upon analyzing the ABI, the "blame" > shifts to the Linux Kernel for MicroBlaze I see your reasoning, and it does make sense that the issue could be within the Linux kernel considering that is the only place where we have reproduced this failure so far. Since you understand microblaze assembly language better than I do, could I ask you to have a look at how the bare-metal interrupt handling is done? Since the bare-metal applications seem to be working correctly with gcc v15, perhaps comparing the bare-metal solution with Linux might be worthwhile? You can find the microblaze bare-metal software here: https://github.com/Xilinx/embeddedsw/tree/master/lib/bsp/standalone/src/microblaze Best regards, Neal Frager AMD
