https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #18 from Surya Kumari Jangala <jskumari at gcc dot gnu.org> --- I git cloned and built flexiblas to see what is the frame size and what is the assembly code generated for the flexiblas C wrapper routine for dgebal. The important assembly code snippets for dgebal.c : // r23-r31 are saved in the callee frame std r23,-72(r1) std r24,-64(r1) ... ... std r31,-8(r1) // allocate the stack frame stdu r1,-112(r1) // save the parameter registers r3-r10 into r23-r30 mr r30,r3 ... mr r23,r10 // some of the param regs are used as temps ld r3,0(r31) lwz r11,16(r3) // populate the param registers appropriately mr r3,r30 ... mr r10,r23 // make the call to the fortran dgebal routine bctrl // restore r1 addi r1,r1,112 // restore r23-r31 ld r23,-72(r1) ... ld r31,-8(r1) // return blr As we can see, the frame size allocated is only 112 out of which 32 is for things like LR, TOC etc. and 72 is needed to save r23-r31. So clearly, the wrapper routine is not allocating any parameter save area in it's frame. Now, the dgebal fortran routine writes into the caller's frame thereby corrupting a callee save register (one of r23-r31). So when control returns back from the wrapper routine to the fortran routine dgeev, we see a corrupted value.
