[Bug target/100799] Stackoverflow in optimized code on PPC

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.