ifx Fortran compiler not finding symbols DSQRT, DABS and CDABS

[hbu]

Hi all!

I updated to Intel oneAPI 2025.1 and now use ifx instead of ifort. We have a C++ code base and link against some Fortran code. During linking I get errors that DSQRT, DABS and CDABS symbols are not found.

I tried to search for these symbols in the libs in C:\Intel\oneAPI\compiler\latest\lib but did not find any of them.

Do these symbols still exist? What options do I have to correctly link my Fortran code base?

Thank you!

[andrew_4619]

What was the exact error message?

DSQRT(1.0D0)

warning #8891: Specific names for intrinsic procedures are obsolescent in Fortran 2018. [DSQRT]

But no errors on compile or link

DSQRT(1.0)
error #6362: The data types of the argument(s) are invalid. [DSQRT]
warning #8891: Specific names for intrinsic procedures are obsolescent in Fortran 2018. [DSQRT]

[hbu]

The error in Visual Studio 2022 says (in German):

Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol "DSQRT" in Funktion "foo".

[Steve_Lionel · Accepted solution]

Were there no messages from the compiler? That linker message would be expected if the argument to the intrinsic was of the wrong type, so that the compiler would assume it was an external procedure (and the message would say so.) 

[JohnNichols]

Error LNK2019 Reference to unresolved external symbol "DSQRT" in function "foo".

using Google translate. 

[hbu]

@Steve_LionelIndeed, I get some compiler warnings saying exactly what you suggested:

foo.f(131): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [CDABS]

foo.f(125): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [DSQRT]

foo.f(1386): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [DABS]

[hbu]

I changed the functions

cdabs --> cabs
dsqrt --> sqrt
dabs --> abs

and the code links fine now. Thank you!

[Steve_Lionel]

Good to hear. If you have need to describe a problem to us in the future, please include ALL of the build messages, not just the last one. It is also extremely helpful to include a small (if possible) but complete example that demonstrates the problem.

Changing from the specific names to the generic names is the right move, as specific names are now obsolescent in the standard.

[JohnNichols]

When did the overloading of the operators occur?

Ularc which is classic 72 Fortran was still compiling 6 months ago with out complaining.  

[Steve_Lionel]

Not sure I understand the question. Generic names for intrinsic procedures started with Fortran 90. Even as new intrinsics were added, new specific names (such as DSQRT) were not. Specific names for intrinsics are obsolescent and should not be used, but they still work if the types of the arguments are correct.

[JohnNichols]

Overloading is taking a subroutine say foo(integer) and foo(double) before we had ifoo and dfoo and now you do not.  Nice, I had not picked this up.  

[Steve_Lionel]

You might find my discussion in Doctor Fortran in "No Reserve" - Doctor Fortran interesting.