https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Janne Blomqvist from comment #3)
> > 1) When compiling an external procedure, for character(len=1) arguments we
> > don't generate the hidden string length argument. And similarly when calling
> > an external procedure, if a len=1 character is passed, we omit the hidden
> > string length argument. This, I believe, is what Paul is suggesting in the
> > previous comment?
> 
> Unfortunately, this would not work :-(
> 
> While looking at the R source, I have also found some occurences
> where 'F' was spelled out 'Full'.

Ah, indeed. 

> Also, what could be done with CALL FOO ('a', 'bcd') ?

My idea would be to not pass the hidden string length for the 'a' argument, but
pass it for the 'bcd' argument.

But as you mention above, there are indeed several ways in which his heuristic
can be broken.

I have a vague memory that other Fortran compilers have special-cased length-1
string arguments, though.

> > 2) External procedures with character arguments are compiled and called as
> > varargs functions. This is what Thomas is suggesting, except unconditionally
> > and not controlled by an option.
> 
> Not an option, unfortunately :-(
> 
> This would bring back PR 87689, and this was an ABI breakage on
> a primary GCC platform (POWER) with perfectly standard-compliant
> code.

Wasn't the problem here that the caller was using varargs, while the callee was
compiled as a normal function, thus causing the mismatch?

So my suggestion was that external procedures be compiled as varargs as well,
which would make the caller and callee ABI's to match.

But now that I think about it, it wouldn't help this LAPACK case, as here the C
side has a non-varargs prototype so the C caller will in any case not use the
varargs convention. And I've never seen any C code defining prototypes to
Fortran procedures as varargs either, so I guess this option is a non-starter.

Bluh.

> > I'm not really happy with either of these, but the third option, of fixing
> > all Fortran-calling code out there isn't realistic either.
> 
> Currently, I am leaning towards using an option with a mandatory
> warning (no way to turn it off) which does not push any string lenghts
> onto the stack at all, something like -fbroken-character-abi,
> which we would use for external procedures without an explicit interface.

Hmm, wouldn't this completely break procedures with "character(len=*)" dummy
arguments? Or did mean that it would be used only for length=1 strings?

> I can also extend -fc-prototypes so that it also issues prototypes
> for any global procedures outside of BIND(C), or add a new option.

This might be useful.

Reply via email to