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

ifx Fortran compiler not finding symbols DSQRT, DABS and CDABS

hbu
新手
1,640 次查看

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!

0 项奖励
1 解答
Steve_Lionel
名誉分销商 III
1,556 次查看

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

在原帖中查看解决方案

0 项奖励
11 回复数
andrew_4619
名誉分销商 III
1,633 次查看

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]

 

 

0 项奖励
hbu
新手
1,600 次查看

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

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


0 项奖励
Steve_Lionel
名誉分销商 III
1,557 次查看

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

0 项奖励
JohnNichols
重要分销商 III
1,534 次查看

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

using Google translate. 

0 项奖励
hbu
新手
1,512 次查看

@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]

0 项奖励
hbu
新手
1,508 次查看

I changed the functions

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

and the code links fine now. Thank you!

0 项奖励
Steve_Lionel
名誉分销商 III
1,454 次查看

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
重要分销商 III
1,438 次查看

When did the overloading of the operators occur?

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

0 项奖励
Steve_Lionel
名誉分销商 III
1,373 次查看

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.

0 项奖励
JohnNichols
重要分销商 III
1,372 次查看

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.  

 

0 项奖励
Steve_Lionel
名誉分销商 III
1,317 次查看

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

0 项奖励
回复