Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28465 Discussions

INTRINSIC statement in module causes an error

ur
New Contributor II
1,087 Views

I have to comment out the INTRINSIC statement in the code below with ifort/ifx, but not with gfortran/nvfortran.  Should the INTRINSIC statement be allowed?

 

module M_overload
! allow SIGN(3f) to take a single argument
use, intrinsic :: iso_fortran_env, only : int32
implicit none
private
public :: sign
!intrinsic :: sign ! ifort 2023 bug(?)
interface sign ; module procedure sign_int32;   end interface

contains

elemental function sign_int32(value)
integer(kind=int32),intent(in) :: value
integer(kind=int32)            :: sign_int32
   sign_int32=sign(1_int32,value)
end function sign_int32

end module M_overload

program tryit
use M_overload, only : sign
implicit none
   write(*,*) merge('sign works','sign fails', sign(10).eq.1 .and. sign(-10).eq.-1 )
end program tryit

 

 

1 Solution
Barbara_P_Intel
Moderator
1,012 Views

Good news! I ran this with the coming release of ifort 2021.9.0 and ifx 2023.1.0 and it compiles and runs!

$ ifx --version
ifx (IFX) 2023.1.0 20230216
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

$ ifx tryit.f90
$ a.out
 sign works

View solution in original post

0 Kudos
8 Replies
ur
New Contributor II
1,084 Views

The message I get with ifx 2023 and ifort 2023 is

 

 

xx.f90(23): error #6505: This intrinsic procedure reference contains too few arguments. [SIGN]
write(*,*) merge('sign works','sign fails', sign(10).eq.1 .and. sign(-10).eq.-1 )
-----------------------------------------------^
xx.f90(23): error #6505: This intrinsic procedure reference contains too few arguments. [SIGN]
write(*,*) merge('sign works','sign fails', sign(10).eq.1 .and. sign(-10).eq.-1 )
```
-------------------------------------------------------------------^
compilation aborted for xx.f90 (code 1)

0 Kudos
FortranFan
Honored Contributor II
1,056 Views

It's a compiler bug with being unable to resolve a generic interface.  While it gets addressed, but a clearer instruction per the standard that all the processors will likely also prefer will be to move the `intrinsic` to the scope of the overriding procedure:

 

contains
   elemental function sign_int32(value)
      integer(kind=int32),intent(in) :: value
      integer(kind=int32)            :: sign_int32
      intrinsic :: sign ! move the intrinsic to this subscope
      sign_int32=sign(1_int32,value)
   end function sign_int32

 

ur
New Contributor II
1,037 Views

That does make is less ambigious as just the intrinsic is needed at that point, but the overlaid procedure is in scope, which makes for an

recursive situation.

0 Kudos
Barbara_P_Intel
Moderator
1,013 Views

Good news! I ran this with the coming release of ifort 2021.9.0 and ifx 2023.1.0 and it compiles and runs!

$ ifx --version
ifx (IFX) 2023.1.0 20230216
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

$ ifx tryit.f90
$ a.out
 sign works
0 Kudos
FortranFan
Honored Contributor II
991 Views

@Barbara_P_Intel ,

In your tryit.f90 test, was the line 7 uncommented?  Assuming your test was the code in the original post with line 7 as "!intrinsic :: sign ! ifort 2023 bug(?)"   OP had the line commented out.

Barbara_P_Intel
Moderator
903 Views

@FortranFan, I missed that subtlety on line 7. I get the same error message with the coming release.

0 Kudos
Barbara_P_Intel
Moderator
895 Views

Bug filed, CMPLRLLVM-45073.


Barbara_P_Intel
Moderator
703 Views

The erroneous error message is removed now in the Fortran compilers that were released last week as part of oneAPI HPC Toolkit 2023.2.

Please try it!



0 Kudos
Reply