[Bug fortran/52333] New: Explicit etime interface should work

[Bug fortran/52333] New: Explicit etime interface should work

[pablomme at googlemail dot com]

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

             Bug #: 52333
           Summary: Explicit etime interface should work
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pablomme@googlemail.com


gfortran differs from all other compilers I have access to (Intel's, NAG's,
PathScale's, Portland Group's, Sun's and g95) in that it does not accept
defining an explicit interface to the etime intrinsic:

--

$ cat test_etime.f90

PROGRAM test_etime
 IMPLICIT NONE
 REAL x(2)
 print *,etime(x)
END PROGRAM test_etime

$ cat test_etime_iface.f90

PROGRAM test_etime_iface
 IMPLICIT NONE
 REAL x(2)
 INTERFACE
  REAL FUNCTION etime(x)
   REAL,INTENT(inout) :: x(2)
  END FUNCTION etime
 END INTERFACE
 print *,etime(x)
END PROGRAM test_etime_iface

$ echo "NY" ;\
> for c in gfortran ifort nagfor pathf95 pgf95 g95 sunf95 ; do\
>  $c -o t test_etime.f90 >& /dev/null && a=1 || a=0 ;\
>  rm -f t *.o ;\
>  $c -o t test_etime_iface.f90 >& /dev/null && a=${a}1 || a=${a}0 ;\
>  rm -f t *.o ;\
>  echo "$a <- $c" ;\
> done

NY
10 <- gfortran
01 <- ifort
00 <- nagfor
11 <- pathf95
01 <- pgf95
11 <- g95
01 <- sunf95

--

The above table tells us if each compiler succeeded (1) or failed (0) compiling
the code without (N) or with (Y) an explicit etime interface. Without the
explicit interface the outcome is mixed, but every compiler other than gfortran
will successfully compile the code with the explicit interface (if the compiler
provides an etime extension; nagfor doesn't).

The same thing happens if one uses etime as a subroutine (with a second
argument): gfortran is alone in failing to compile the code if there is an
explicit interface. Using etime as a subroutine and not providing an explicit
interface seems to work on all of the above compilers, including gfortran.

This may be true of other extensions or intrinsics - I can run specific tests
with other compilers if this would be helpful.

[Bug fortran/52333] Explicit etime interface should work

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2012-02-22 03:16:04 UTC ---
Please define fails.  What is the error message
you get?  All procedure included in gfortran's
runtime library are treated as intrinsic
procedures unless you use -std= to restrict
gfortran to a particular standard.  As it is
an intrinsic procedure, etime already has an
explicit interface.  So, trying to re-specify
an interface makes no sense.

[Bug fortran/52333] Explicit etime interface should work

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org 2012-02-22 03:29:28 UTC ---
(In reply to comment #1)
> Please define fails.  What is the error message
> you get?  All procedure included in gfortran's
> runtime library are treated as intrinsic
> procedures unless you use -std= to restrict
> gfortran to a particular standard.  As it is
> an intrinsic procedure, etime already has an
> explicit interface.  So, trying to re-specify
> an interface makes no sense.

Just a follow-up page 283 in F2008,

A procedure shall not have more than one explicit
specific interface in a given scoping unit.


Now, I need to see if specifying an interface block
for a procedure implies the external attribute.  
That would open a whole other can of worms that 
one does not want to open.

[Bug fortran/52333] Explicit etime interface should work

[pablomme at googlemail dot com]

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

--- Comment #3 from pablomme <pablomme at googlemail dot com> 2012-02-22 03:32:14 UTC ---
> Please define fails.  What is the error message you get?

Namely:

$ gfortran -o t test_etime_iface.f90 
/scratch/pl275/ccyZ7sWC.o: In function `MAIN__':
test_etime_iface.f90:(.text+0x4b): undefined reference to `etime_'
collect2: ld returned 1 exit status

gfortran accepts the inteface but ld fails because the intrinsic has been
obscured by a missing external procedure.

> As it is an intrinsic procedure, etime already has an
> explicit interface.  So, trying to re-specify
> an interface makes no sense.

I don't doubt that gfortran's behaviour may be sensible. The "bug" here is that
it behaves differently from 6 other compilers.

About whether this construction makes sense or not, in our code we use this
explicit interface in order to support optional compilation of a C replacement
for etime for compilers that do not offer the extension. At present, gfortran
requires the C replacement because of this problem, but it shouldn't need it.
No biggie, of course, but it'd be nice to see this consistency.

[Bug fortran/52333] Explicit etime interface should work

[pablomme at googlemail dot com]

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

--- Comment #4 from pablomme <pablomme at googlemail dot com> 2012-02-22 03:40:12 UTC ---
Adding "EXTERNAL etime" to the program gives:

--
$ gfortran -o t test_etime_iface.f90 
test_etime_iface.f90:9.15:

 EXTERNAL etime
               1
Error: Duplicate EXTERNAL attribute specified at (1)

$ ifort -o t test_etime_iface.f90 
test_etime_iface.f90(9): error #6409: This name has already been used as an
external procedure name.   [ETIME]
 EXTERNAL etime
----------^
compilation aborted for test_etime_iface.f90 (code 1)
--

Then adding "INTRINSIC etime" gives:

--
$ gfortran -o t test_etime_iface.f90 
test_etime_iface.f90:9.16:

 INTRINSIC etime
                1
Error: EXTERNAL attribute conflicts with INTRINSIC attribute at (1)

$ ifort -o t test_etime_iface.f90 
test_etime_iface.f90(9): error #6409: This name has already been used as an
external procedure name.   [ETIME]
 INTRINSIC etime
-----------^
compilation aborted for test_etime_iface.f90 (code 1)
--

So ifort seems to agree with gfortran in its error messages that providing an
explicit interface to a function implies that the function is EXTERNAL, and
that INTRINSIC is incompatible with EXTERNAL. This seems inconsistent with its
using the intrinsic version if etime when an explicit interface is present, but
there you go..

[Bug fortran/52333] Explicit etime interface should work

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-22 03:49:15 UTC ---
On Wed, Feb 22, 2012 at 03:32:14AM +0000, pablomme at googlemail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333
> 
> --- Comment #3 from pablomme <pablomme at googlemail dot com> 2012-02-22 03:32:14 UTC ---
> > Please define fails.  What is the error message you get?
> 
> Namely:
> 
> $ gfortran -o t test_etime_iface.f90 
> /scratch/pl275/ccyZ7sWC.o: In function `MAIN__':
> test_etime_iface.f90:(.text+0x4b): undefined reference to `etime_'
> collect2: ld returned 1 exit status
> 
> gfortran accepts the inteface but ld fails because the intrinsic has been
> obscured by a missing external procedure.

Well, obscured may be misleading.  gfortran's intrinsic 
procedure is named _gfortran_etime.  When you give the
interface block, gfortran is clearly treating this as
an external procedure.  I'm still reading through Sec. 12
of F2008 to see if this is the expected behavior.

> > As it is an intrinsic procedure, etime already has an
> > explicit interface.  So, trying to re-specify
> > an interface makes no sense.
> 
> I don't doubt that gfortran's behaviour may be sensible.
> The "bug" here is that it behaves differently from 6 other compilers.

Well, the other compilers do not make a very striction
distinction between an intrinsic and external procedure
for procedures that are supplied with the compiler but
are not listed in the standard.  gfortran is very consistent
with how it treats precedures it supplies in its runtime
library.

> About whether this construction makes sense or not, in our code we use this
> explicit interface in order to support optional compilation of a C replacement
> for etime for compilers that do not offer the extension. At present, gfortran
> requires the C replacement because of this problem, but it shouldn't need it.
> No biggie, of course, but it'd be nice to see this consistency.

What happens with all your compilers if you supply
an explicit interface for say DSIN.

[Bug fortran/52333] Explicit etime interface should work

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-22 04:16:21 UTC ---
On Wed, Feb 22, 2012 at 03:40:12AM +0000, pablomme at googlemail dot com wrote:
> 
> So ifort seems to agree with gfortran in its error messages that providing an
> explicit interface to a function implies that the function is EXTERNAL, and
> that INTRINSIC is incompatible with EXTERNAL. This seems inconsistent with its
> using the intrinsic version if etime when an explicit interface is present, but
> there you go..
> 

Thanks for testing.  This points at the other
can of worms I mentions.  Old code sometimes
contains 'external etime', and gfortran will
expect a user supplied routine.  It will not
use _gfortran_etime until the programmer
removes the offending statement.  I've closed
a few bug reports about this and have taken
some heat about gfortran's behavior.  In the
end, we decided that the libgfortran namespace
should be segregated from the user's namespace.

[Bug fortran/52333] Explicit etime interface should work

[pablomme at googlemail dot com]

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 :-)

[Bug fortran/52333] Explicit etime interface should work

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Closing as WONTFIX. Please reopen if you disagree.