https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |linkw at gcc dot gnu.org
--- Comment #20 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #4)
> The disassembly says this is powerpc64le. Possibly interesting fact: the
> offsets used above the stack frame are 400, 432, 440, which all correspond
> to the parameter save area. I don't see any reason that DGEBAL should have
> a parameter save area though since all parameters can be passed in regs.
This also confuses me, since the function prototype
SUBROUTINE DGEBAL( JOB, N, A, LDA, ILO, IHI, SCALE, INFO )
only has eight parameters, by looking into it the reason is that the first
parameter
"CHARACTER JOB"
has one more hidden associated length argument.
"For arguments of CHARACTER type, the character length is passed as a hidden
argument at the end of the argument list. " as said in [1], so this function
actually has nine (more than eight) doubleword arguments, then it does need one
parameter save area.
[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
Surya's analysis looks reasonable to me, the current stub scheme with function
pointer call in C doesn't match the Fortran side.
