I am converting from C++ compiler 12.1 to 13.1 and some previously building code is no longer building. It appears that our code that calls pow(float,float) was compiling to call the overload signature double pow(double, double), but now with 13.1 I get a linker error as follows:
...error LNK2019: unresolved external symbol "float __cdecl pow(float,float)...
So 2 questions:
1-Why is there no implementation of float pow(float,float)? You do have powf, but powf is a C language function, and with C++ there should be an overload of pow for float arguments and returning a float. Since compatibility with Microsoft seems like a high priority, you may also consider that they provide the pure float overload of pow.
2-Curious why the use of float x = pow(float,float) no longer links when it did in v12.1.
Thanks in advance.
If you set -std=c99 and
this ought to work. Your "there is no such" would be verified if you don't fulfill the conditions.
Attempting to use C99 features is a sure way toward incompatibility with Microsoft, but it should not be a problem with other currently maintained compilers.
Visual Studio 2012 Ultimate edition with update 3 installed. Our code uses declaractions in the Intel file <mathimf.h>
As for the calling convention, I am building for x64 platform, where Visual Studio does not present the compiler setting for calling convention. I see it when configured for Win32, but it disappears when I switch to x64. Maybe this is the issue? I will put together a small demo app and update asap.
Responding to TimP, I am trying to use pow for floats, not powf. So I'm not trying to use C99, only observing that powf is supposed to be a C99 function and I found that declared in your <mathinf.h> file, but I do not find float pow(float,float). I am trying to use pow for floats, which should always exist for C++. Maybe <mathimf.h> is the wrong declaration for me to be using? Please advise.
I cant check right now but I don't expect mathimf to offer a bypass of c typing. you still have the traditional method where pow takes double returns double but your definition must not conflict with std header.
this rules out some optmizagions
I've tried creating something to reproduce this, but have been unsuccessful. Can you send a buildable test case that shows the unresolved symbol? I'm guessing that the compiler/linker options being used may have an impact too, so please include those.
Thanks, I have tried creating a tiny program that isolates the issue but so far no match for the offending behavior. Will post again when I can get it concisely demonstrated.
By the way, I am doing nothing to link with a particular library in order to link to this pow function. I presume it is one of the default libraries, but can anyone identify which one it is for the Windows environment?
The libraries normally linked with ICL would include both scalar and simd parallel versions of powf() as well as pow(). If none of the usual libraries from Intel or Microsoft satisfy the reference, it's probably due to the compiler seeing your reference as not matching one of the standard functions, thus expecting you to supply the function yourself.