https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #8 from anlauf at gcc dot gnu.org ---
I looked at this one again, also at the fortran-dump.
Consider:
subroutine s1
intrinsic :: atan
real :: r = 1.
print *, atan (-1.d0,r)
end
subroutine s2
external :: atan
real :: r = 1.
print *, atan (-1.d0,r)
end
subroutine s3
real :: r = 1.
print *, atan (-1.d0,r) ! Should give error similar to s1 case
end
subroutine s4
real :: r = 1.
print *, atan (-1.d0,r) ! Reasonable diagnostics
contains
elemental function atan (x, y)
real, intent(in) :: x, y
real :: atan
atan = atan2 (x, y)
end function atan
end
Subroutine s1 gets diagnosed with:
pr113412.f90:4:10:
4 | print *, atan (-1.d0,r)
| 1
Error: Generic function 'atan' at (1) is not consistent with a specific
intrinsic interface
which is correct. The fortran-dump therefore correctly shows:
TRANSFER atan[((-1.0000000000000000_8) (s1:r))]
Subroutine s3 gives
pr113412.f90:15:10:
15 | print *, atan (-1.d0,r) ! Should give error similar to s1 case
| 1
Error: Too many arguments in call to 'atan' at (1)
which looks like resolution happens slightly different.
Subroutine s4 shows that regular interfaces are handled reasonably:
pr113412.f90:20:10:
20 | print *, atan (-1.d0,r) ! Should give error similar to s1 case
| 1
Error: Type mismatch in argument 'x' at (1); passed REAL(8) to REAL(4)
NAG gives consistent diagnostics for s1 and s3, as does flang.
(Nvidia is not so consistent, and Intel ICEs).
