Re: do we expect compiler to catch this?

[Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE]

Quoting Uttam Pawar <uttamp@us.ibm.com>:
> > This is a quality of implementation issue, not than a correctness issue.
> It
> > would be great if we caught this, but we don't have to.  On the other hand,
> > with an explicit interface (as in the case of an intrinsic), we should
> probably
> > catch this.  Which we don't:
> > schluter@pcl247d:~/src> cat t.f90
> > CALL f(1.)
> > CONTAINS
> > subroutine f(x)
> >  intent(out) :: x
> >  x = 2.
> > end subroutine f
> > end
> > schluter@pcl247d:~/src> pgf90 t.f90
> > PGF90-W-0193-Argument number 1 to f does not match INTENT (OUT) (t.f90: 1)
> >   0 inform,   1 warnings,   0 severes, 0 fatal for MAIN
> > schluter@pcl247d:~/src> gfortran t.f90
> > schluter@pcl247d:~/src>
>
> Yes, but this code is still in a single file and compiler has access to
> all the information to determine the validity of the code. But as Steve
> said, it is possible to have code compiled separately (and intrinsic in
> a library), in that case, it's difficult to catch this type errors at
> the compile time.

If the code you gave is also in a single file, the compiler could (and IMO
should) catch this, that's why I referred to quality of implementation.

Another related issue:
   schluter@pcl247d:~/src> cat t.f90
   CALL f(1.)
   CALL f(2.,3.)
   end
   schluter@pcl247d:~/src> gfortran -c t.f90 -pedantic
   schluter@pcl247d:~/src>

This should also give an error (maybe even without -pedantic, but there might be
cases where one likes to call a C vararg function).

Another issue with external symbols that we might want to catch is the
following:
   schluter@pcl247d:~/src> cat t.f90
   CALL f(1.)
   end

   subroutine a(y)
     x = f(y)
   end subroutine a
   schluter@pcl247d:~/src> gfortran -c t.f90
   schluter@pcl247d:~/src>
i.e. f being used as subroutine in one place and as a function in another, this
might be a thing that people do deliberately, though.

- Tobi