topic Re: Strange bug with overloading intrinsic sqrt in Intel® Fortran Compiler

Strange bug with overloading intrinsic sqrt

Harald1 — Wed, 14 Apr 2021 20:07:05 GMT

The following (almost) minimal code triggers a strange bug with ifort & ifx 2021.2:

module mod1 implicit none real, parameter :: z = sqrt (0.0) end module mod1 module mod2 implicit none type t real :: a = 0. end type interface sqrt module procedure sqrt end interface contains function sqrt (a) type(t), intent(in) :: a type(t) :: sqrt sqrt% a = a% a end function sqrt end module mod2 program test use mod1 use mod2 implicit none type(t) :: x, y y = sqrt (x) y% a = sqrt (x% a) end program test

I obtain the following error:

% ifort intel-sqrt-ifc.f90 intel-sqrt-ifc.f90(28): error #6284: There is no matching specific function for this generic function reference. [SQRT] y% a = sqrt (x% a) ---------^ compilation aborted for intel-sqrt-ifc.f90 (code 1)

The code compiles flawlessly with NAG and with Nvidia.

Re: Strange bug with overloading intrinsic sqrt

FortranFan — Wed, 14 Apr 2021 21:00:56 GMT

Please submit a support request with Intel online service center if you are able to.

In the meantime, if you need to work your code with Intel Fortran in addition to other compilers, you can try this workaround which I expect will work with those other compilers as well:

program test use mod1 use mod2 implicit none type(t) :: x, y y = sqrt (x) block intrinsic :: sqrt y% a = sqrt (x% a) end block end program test

Re: Strange bug with overloading intrinsic sqrt

IanH — Wed, 14 Apr 2021 21:16:46 GMT

Alternatively, rename the specific procedure.

Re: Strange bug with overloading intrinsic sqrt

andrew_4619 — Wed, 14 Apr 2021 21:55:07 GMT

My contribution should fix your problem but maybe in not the most helpful. Please consider overloading intrinsics as a similar activity as juggling with chain saws.

Re: Strange bug with overloading intrinsic sqrt

jimdempseyatthecove — Thu, 15 Apr 2021 01:47:23 GMT

A generic interface (replacing an intrinsic interface) does not extend the interface with alternate arguments (as is done with C++). It replaces it.

You may have luck defining the interface sqrt to use, for example, three interface functions:

sqrt_t(ArgOfType_t)
sqrt_real(ArgOfType_real)
sqrt_double(ArgOfType_double)

In the case of the implementation of the last two, you would have to hide your generic interface from the intrinsic interface (as mentioned by earlier post or by other means).

Jim Dempsey

Re: Strange bug with overloading intrinsic sqrt

FortranFan — Thu, 15 Apr 2021 03:14:11 GMT

@jimdempseyatthecove wrote: A generic interface (replacing an intrinsic interface) does not extend the interface with alternate arguments (as is done with C++). It replaces it. ..

Jim, I don't understand what you mean here.

Fortran standard document only seems to mention the "replaces it" aspect i.e., an override semantics when a generic invocation is consistent with a specific procedure in a generic interface and an intrinsic procedure. This is not the case with the original post where the generic interface can be viewed as "extending" the interface.

Re: Strange bug with overloading intrinsic sqrt

FortranFan — Thu, 15 Apr 2021 03:19:34 GMT

@IanH wrote: Alternatively, rename the specific procedure.

Or make it PRIVATE.

module mod2 implicit none private type, public :: t real :: a = 0. end type generic, public :: sqrt => sqrt contains function sqrt (a) type(t), intent(in) :: a type(t) :: sqrt sqrt% a = a% a end function sqrt end module mod2

C:\Temp>ifort /c /standard-semantics /warn:all /stand:f18 intel-sqrt-ifc.f90 Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.2.0 Build 20210228_000000 Copyright (C) 1985-2021 Intel Corporation. All rights reserved. C:\Temp>

Re: Strange bug with overloading intrinsic sqrt

Harald1 — Thu, 15 Apr 2021 06:54:20 GMT

@andrew_4619 : I strongly disagree. I overload intrinsics for use with derived types all the time. This makes programming much easier.

Re: Strange bug with overloading intrinsic sqrt

Harald1 — Thu, 15 Apr 2021 06:59:10 GMT

@jimdempseyatthecove :

Jim, I do not see any replacement of an intrinsic. It was always legal to add interfaces to an existing one, which is sort of implicit for the intrinsics.

Let me note that replacing in the main the line

use mod1

use mod1, only: z

makes the code compile. Thus module mod1 is the/a troublemaker.

My question is: how can that happen?

Re: Strange bug with overloading intrinsic sqrt

andrew_4619 — Thu, 15 Apr 2021 08:57:25 GMT

The overloading is perfectly legal and may generate some benefits, each to their own. My problem is that I understand Fortran, when you overload you have changed the meaning of an intrinsic. A third party starting to look at the code reads "apple" and expects it to be an apple when in fact it may now be a pear. If you made a unique thing e.g sqrt_t than you can still have the same functionality whilst being clearer.

Re: Strange bug with overloading intrinsic sqrt

Steve_Lionel — Thu, 15 Apr 2021 14:02:12 GMT

You cannot replace an intrinsic (for standard argument types) with generic extension. I recall there was a case recently where the Intel compiler was improperly allowing this in some circumstances. The only thing you can do with extension of a generic intrinsic is to define it for argument lists not specified by the standard.

Re: Strange bug with overloading intrinsic sqrt

FortranFan — Thu, 15 Apr 2021 19:18:45 GMT

@Steve_Lionel wrote: You cannot replace an intrinsic (for standard argument types) with generic extension. I recall there was a case recently where the Intel compiler was improperly allowing this in some circumstances. The only thing you can do with extension of a generic intrinsic is to define it for argument lists not specified by the standard.

I don't understand what this means. The standard, per section 15.4.3 Specification of the procedure interface, suggests it is indeed possible to override an intrinsic procedure in the case of "standard argument types".

The confusion that can come about is with the programmer choice of specific procedure names in a generic interface, the standard asks that it be a nonintrinsic procedure with an explicit interface. Compiler implementations (e.g., gfortran) have had problems with this from what I've seen. To the extent a coder doesn't make it too confusing, a conforming processor can be expected to handle overrides such as this: as to whether it's advisable is a different matter altogether.

module m private generic, public :: sqrt => sqrt contains function sqrt( x ) result( r ) real, intent(in) :: x real :: r print *, "Using pocket calculator method:" r = exp( 0.5*log(x) ) end function end module use m print *, "sqrt(2.0) = ", sqrt(2.0) end

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 q.f90 Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.2.0 Build 20210228_000000 Copyright (C) 1985-2021 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.28.29337.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:q.exe -subsystem:console q.obj C:\Temp>q.exe Using pocket calculator method: 1.414214 C:\Temp>

The case where Intel compiler was non-conforming had to do with intrinsic operations, not intrinsic procedures. The standard never intended an override of intrinsic operations but that is different from intrinsic procedures.

Re: Strange bug with overloading intrinsic sqrt

Steve_Lionel — Thu, 15 Apr 2021 21:25:44 GMT

@FortranFan , would you please point to the specific paragraph or lines of the standard that, according to you, allows one to replace an intrinsic procedure through generic extension? I don't think this is correct, especially as it would violate 15.4.3.4.1p2, which says (in part), "The rules specifying how any two procedures with the same generic identifier shall differ are given in 15.4.3.4.5. They ensure that any generic invocation applies to at most one specific procedure."

The same applies to generic operators. You can extend them by adding meanings the standard does not provide, but you can't, for example, make "2+2" call your own addition routine, just as you can't replace SQRT(REAL) unless you completely replace the standard intrinsic name in a scope.

Re: Strange bug with overloading intrinsic sqrt

FortranFan — Fri, 16 Apr 2021 23:06:44 GMT

@Steve_Lionel wrote: .. would you please point to the specific paragraph or lines of the standard that, according to you, allows one to replace an intrinsic procedure through generic extension? ..

It will be more helpful if you first explain what you meant by, "You cannot replace an intrinsic (for standard argument types) with generic extension." By this statement, did you meant the following code does not conform to the standard? (note: it's a variant of the snippet upthread but the Fortran 2018 GENERIC statement has been replaced by the Fortran 90 and later INTERFACE block to allow parsing with different compilers). If that is what you meant, then you will find the standard and almost all the compilers disagree.

module m interface sqrt module procedure sqrt end interface public :: sqrt !<-- superfluous; included for one compiler's sake contains function sqrt( x ) result(r) real, intent(in) :: x real :: r write(*,*) "Using pocket calculator method:" r = exp( 0.5*log(x) ) end function end module use m, only : sqrt real :: x x = sqrt(2.0) write(*, "('sqrt(2.0) = ', f14.6)") x end

Here the generic interface identifier is "overriding" the intrinsic SQRT procedure; one then has to employ the INTRINSIC attribute to reference the intrinsic SQRT.

Arguably what the standard does is effectively permission-by-omission here. Unlike with defined operations where in section 15.4.3.4.2 Defined operations, paragraph 1, lines 10 thru' 13 (page 305) where the standard states, "If the operator is an intrinsic-operator (R608), the number of dummy arguments shall be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic operation (10.1.5)," there is no corresponding stipulation with intrinsic procedures and my take is it's by design.

The notion of allowing an override of an intrinsic procedure is then spread subtly across section 15.4.3. And statements such as, "If a generic invocation is consistent with both a specific procedure from an interface and an accessible intrinsic procedure, it is the specific procedure from the interface that is referenced," provide a gentle hint toward its support. One will be hard-pressed to find a processor conformant to Fortran 90 even that does not compile the code posted in this thread to a program giving the following output:

C:\Temp>f90 q.f90 Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C) Copyright 2003 Compaq Computer Corp. All rights reserved. q.f90 Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /subsystem:console .. /out:q.exe C:\Temp>q.exe Using pocket calculator method: sqrt(2.0) = 1.414214 C:\Temp>

Re: Strange bug with overloading intrinsic sqrt

Steve_Lionel — Sat, 17 Apr 2021 20:11:14 GMT

You are correct. I was confusing the rule for operators with that for intrinsics.