Re: [gfortran] Fix PR 20178: Implement g77 / f2c calling conventions

[Paul Brook <paul at codesourcery dot com>]

On Saturday 05 March 2005 15:32, Tobias Schlüter wrote:
> Until I mentioned it on the mailing list, noone had complained that we
> didn't implement a calling convention compatible with g77.  Unfortunately,
> people seem to care, so I implemented it.
>
> The g77 calling convention requires two things for function results that we
> didn't do:
> - scalar COMPLEX functions return via a hidden argument
> - default REAL functions return a C double
>
> I implemented this, but it is currently only enabled via a command-line
> option.  If we decide that this is the right way, I propose making
> -fno-second-underscore the default also, as compatibility with g77 will
> then not be required for this either.

I vote for keeping the current default, and leaving -ff2c as an option. I'm 
sure we will get complaints whatever we choose, so we may as well choose the 
most efficient option. (assuming a sane C abi for that particular target of 
course ;-)

> If on the other hand we decide that the f2c calling convention should be
> the default (I'm against it, see the PR's audit trail for a few arguments
> in both ways), someone should implement the necessary fixes to those
> routines in libgfortran that are affected by the calling conventions (i.e.
> those which can be passed as an actual argument, and which are REAL*4 or
> COMPLEX).

The library should be fixed regardless of the default.

> This patch has a few warts, but hey -- it comes with documentation :-)
> (taken from g77 for the most part).  The last hunk to gfc_get_function_type
> is especially nasty, but it works because we will always get the tree for
> the symbol there.
>
> Patch bubblestrapped and regtested.  Documentation built with make dvi.  It
> also passes the testsuite with -ff2c made the default -- except for
> gfortran.fortran-torture/execute/csqrt_1.f90 which uses affected functions
> as actual arguments.

I'd prefer it if this were fixed. Making the complier abort when we pass an 
abi sensitive intrinsic as an actual argument is ok as a temporay measure.  
Generating bad code is not. I guess the proper fix involves building two 
copies of the specific library functions with different names and compilation 
flags.


> + ?else if (sym->attr.function)
> + ? ?{
> + ? ? ?/* Correctly set the result dummy argument. ?*/
> + ? ?}

This looks wrong, or at best pointless and confusing.

> + ?/* f2c calling conventions require a scalar default real function to
> + ? ? return a double precision result. ?Convert this back to default
> + ? ? real. ?We only care about the cases that can happen in Fortran 77.
> + ?*/
> + ?if (gfc_option.flag_f2c && sym->ts.type == BT_REAL 
> + ? ? ?&& sym->ts.kind == gfc_default_real_kind && !sym->attr.pointer
> + ? ? ?&& !(sym->result && (sym->result->attr.pointer
> +??????????????????????? ? || sym->result->attr.dimension)))
> + ? ?se->expr = fold_convert (gfc_get_real_type (sym->ts.kind), se->expr);


> ? ?else
> - ? ?type = gfc_sym_type (sym);
> + ? ?{
> + ? ? ?type = gfc_sym_type (sym);
> + ? ? ?if (gfc_option.flag_f2c
> +??????? ?&& sym->ts.type == BT_REAL
> +??????? ?&& sym->ts.kind == gfc_default_real_kind)
> +???????{

Shouldn't these use sym->attr.always_explicit?
They are definitely incorrect. For example:

program test
  real, target :: f
  real, pointer :: q
  real :: g
  f = 1.0
  q=>f
  g = foo(q)
  if (g .ne. 1.0) call abort
contains
function foo (p)
  real, pointer :: foo
  real, pointer :: p
  foo => p
end function
end program

I'm mildly surprised that the callee side of the return value didn't need an 
explicit cast somewhere. I suspect there are cases where we force a 
conversion even if the expressions should already be the correct type.

Paul