https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Peter Bergner from comment #25) > CCing Mike and David for possible comments about the possible workarounds > mentioned in Comment 23 and Comment 24. Doing the workaround on the caller side is impossible, this is for calls from C/C++ to Fortran code, directly or indirectly called and there is nothing the compiler could use to guess that it actually calls Fortran code with hidden Fortran character arguments. But I still think the workaround is possible on the callee side. Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the function, then there is no easy way but expect the parameter save area (ok, sure, it could just load from the assumed parameter location and don't assume the rest is there, nor allow storing to the slots it loaded them from). But that is actually not what BLAS etc. suffers from. If you have something like subroutine foo (a, b, c, d, e, f, g, h) character a integer b, c, d, e, f, g, h call bar (a, b, c, d, e, f, g, h) end subroutine foo then the DECL_HIDDEN_STRING_LENGTH argument isn't used at all, on the callee side the user said that one should treat it as if the length of a is 1, so whatever the caller passes is unimportant and when passing to further calls it will just use 1: void foo (character(kind=1)[1:1] & restrict a, integer(kind=4) & restrict b, integer(kind=4) & restrict c, integer(kind=4) & restrict d, integer(kind=4) & restrict e, integer(kind=4) & restrict f, integer(kind=4) & restrict g, integer(kind=4) & restrict h, integer(kind=8) _a) { <bb 2> : bar (a_2(D), b_3(D), c_4(D), d_5(D), e_6(D), f_7(D), g_8(D), h_9(D), 1); return; } It would seem that the _a argument is useless, but as explained in PR90329 that is because in Fortran you can call foo ("foo", 1, 2, 3, 4, 5, 6, 7) without interfaces etc. and the first argument could be character, character(len=1), character(len=3) or character(len=*) etc. And only in the last case the argument is actually needed, in other cases it is ignored. So, the workaround could be for the case of unused DECL_HIDDEN_STRING_LENGTH arguments at the end of PARM_DECLs don't try to load those at all and don't assume there is parameter save area unless the non-DECL_HIDDEN_STRING_LENGTH or used DECL_HIDDEN_STRING_LENGTH arguments actually require it.