Another one on Intrinsics: can DATE_AND_TIME be PURE?

[FortranFan]

IanH just raised the point on the PURE attribute of intrinsic special functions such as SIN.  It looks like Intel (Steve) accepted the argument and have opened an incident for developers to work on the issue.

Along the same lines, is it possible to mark DATE_AND_TIME as PURE and not require an explicit interface since it is an intrinsic?  Or does it not make sense here because it involves real-time system clock?

Thanks, 

[fortran]

MODULE TestDateMod

CONTAINS

  !.. Routine to get real-time date   

  PURE ELEMENTAL SUBROUTINE GetDate(Now_Year,Now_Month,Now_Day)

      !.. Argument list

      INTEGER(4), INTENT(OUT) :: Now_Year

      INTEGER(4), INTENT(OUT) :: Now_Month

      INTEGER(4), INTENT(OUT) :: Now_Day

      !,, Local variables

      INTEGER(4) :: Date_Time(8)

      CHARACTER(LEN=12) :: RC(3)

      CALL DATE_AND_TIME(RC(1),RC(2),RC(3),Date_Time)

      Now_Year = Date_Time(1)

      Now_Month = Date_Time(2)

      Now_Day = Date_Time(3)

      !..

      RETURN

   END SUBROUTINE GetDate

END MODULE TestDateMod

[/fortran]

The above generates this error:

[plain]

------ Build started: Project: testdate, Configuration: Debug|Win32 ------

Compiling with Intel(R) Visual Fortran Compiler XE 14.0.0.103 [IA-32]...

TestDate.f90

C:\\dev\\TestDate.f90(17): error #7137: Any procedure referenced in a PURE procedure,

including one referenced via a defined operation or assignment, must have an explicit interface

and be declared PURE.   [DATE_AND_TIME]

compilation aborted for C:\\dev\\TestDate.f90 (code 1)

Build log written to  "file://C:\\dev\\Debug\\Win32\\testdateBuildLog.htm"

testdate - 2 error(s), 0 warning(s)

---------------------- Done ----------------------

[/plain]

[Steven_L_Intel1]

The standard specifies that all intrinsic functions are PURE. The same does not hold for intrinsic subroutines. The standard says, "The subroutine MOVE ALLOC and the elemental subroutine MVBITS are pure. No other standard intrinsic subroutine is pure."

By the way, the issue you referenced was specifically about the how the compiler compares interfaces when passing functions. The compiler already knew that SIN was pure.