http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333

--- Comment #7 from pablomme <pablomme at googlemail dot com> 2012-02-22 
04:42:30 UTC ---
> What happens with all your compilers if you supply
> an explicit interface for say DSIN.

For DSIN all of them behave like gfortran:

--
$ cat test_dsin.f90
PROGRAM test_dsin
 IMPLICIT NONE
 INTERFACE
  REAL(kind(1.d0)) FUNCTION dsin(x)
   REAL(kind(1.d0)),INTENT(in) :: x
  END FUNCTION dsin
 END INTERFACE
 print *,dsin(3.1415926539d0)
END PROGRAM test_dsin

$ gfortran -o t test_dsin.f90 
/scratch/pl275/ccxxjAPs.o: In function `MAIN__':
test_dsin.f90:(.text+0x49): undefined reference to `dsin_'
collect2: ld returned 1 exit status

$ ifort -o t test_dsin.f90 
/scratch/pl275/ifortLhFYMA.o: In function `MAIN__':
test_dsin.f90:(.text+0x3c): undefined reference to `dsin_'

$ pathf95 -o t test_dsin.f90 
/scratch/pl275/cco.4imSrS: In function `MAIN__':
/a/tcmsf1/home/users/pl275/wip/etime/dsin/test_dsin.f90:8: undefined reference
to `dsin_'

$ pgf95 -o t test_dsin.f90 
/scratch/pl275/pgf95Wl_cqLvvGVlu.o: In function `test_dsin':
/a/tcmsf1/home/users/pl275/wip/etime/dsin/./test_dsin.f90:8: undefined
reference to `dsin_'

$ sunf95 -o t test_dsin.f90 
test_dsin.o: In function `MAIN_':
test_dsin.f90:(.text+0x97): undefined reference to `dsin_'

$ g95 -o t test_dsin.f90 
/scratch/pl275/ccQEFFM1.o: In function `MAIN_':
test_dsin.f90:(.text+0x72): undefined reference to `dsin_'

$ nagfor -o t test_dsin.f90 
NAG Fortran Compiler Release 5.2(721)
[NAG Fortran Compiler normal termination]
test_dsin.o: In function `main':
test_dsin.012193.c:(.text+0x6a): undefined reference to `dsin_'
collect2: ld returned 1 exit status
--

Really inconsistent behaviour; as you point out, they seem to be making an
exception for ETIME as an extension as opposed to standard intrinsics.

> In the end, we decided that the libgfortran namespace
> should be segregated from the user's namespace.

That sounds like the right thing to do, but there is also the question of
whether you want to support this type of "legacy compiler behaviour" that other
compilers exhibit, which people tend to expect, and whose lack might get you a
number of additional bug reports.

Anyway, thanks for the attention! Feel free to close this bug as
resolved/duplicate/invalid/wontfix :-)

Reply via email to