Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

ipo crashes with fmax

nayakmc
Beginner
624 Views
I have some problems compiling code that uses fmax/fmaxf from on Visual Studio 2010 in a Release|Win32 configuration. On the following simple program, ipo crashes and the build fails. The executable however is still generated from the code. How can I fix this problem?

Thank you,
Jayanth

#include
 
#include
 
intmain(intargc,char*argv[])
{
std::cout<

The error that I receive is 
1>------ Build started: Project: FMaxTest, Configuration: Release Win32 ------
1>ipo : warning #11021: unresolved fmax
1> Referenced in ipo_73005obj.obj
1>ipo : error #11023: Not all components required for linking are present on command line
1> xilink: executing 'link'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

0 Kudos
10 Replies
Shenghong_G_Intel
624 Views
Hi nayakmc,

This is an known issue in our problem tracking system and will be fixed in future release.

Following are some related descriptions:

This issue can only be reproduced when you are using x86 platform instead of intel64 platform in release mode.
Here are some possible workarounds for your reference to make it work:
(1) Use intel64 platform.
(2) Use "debug" mode, or enable runtime checks in release mode to avoid the error (Project -> Properties -> C/C++ -> Code Generation -> Basic Runtime Checks -> RTC1).
(3) Disable IPO or use O1 instead of O2/3.

Please feel free to let me know if you still have some issues.

Thanks,
Shenghong

0 Kudos
SergeyKostrov
Valued Contributor II
624 Views
...
Here are some possible workarounds for your reference to make it work:

(1) Use intel64 platform.
...


From my point of view this is not a workaround. This is a complete platform change and you know this is not
an easy task! Could you imagine everybody is forced to change a platform in case of a bug in some API?

Best regards,
Sergey

0 Kudos
JenniferJ
Moderator
624 Views
Yeh, the 1st one is not a valid work-around. It only says that this issue does not affect the x64 compiler.

But the other 3 work-arounds should work and easily applied.

/Qipo is on by default in "Release" config. It can be truned off. You can still use -O2 or -O3 though.

Thanks,
Jennifer
0 Kudos
jimdempseyatthecove
Honored Contributor III
624 Views
What happens if you replace "fmax(10.0,11.0)" with "std::max(10.0,11.0)"

If this works, then a work around might be to

-Dfmax=std::max


(assumes #include )

Jim Dempsey
0 Kudos
Shenghong_G_Intel
624 Views
Hi Sergey,

Thank you for correction. Here it is not good to say it as a workaround. As Jennifer said, here I was trying to tell the information that this is only reproducible in intel 64 mode.
In a real project, it should be really a hard task to change platform.

Thanks,
Shenghong
0 Kudos
Shenghong_G_Intel
624 Views
Hi Jim, It works in fact. It should also be a good work around. Also to be mentioned, NOT all intel math library functions will cause this issue. Currently as i known, fmax and fmin will cause the issue. Thanks, Shenghong
0 Kudos
TimP
Honored Contributor III
624 Views
I'm surprised to see fmax() in use in C++ syntax, as it's a C99 function, although apparently most C++ compilers support it.
I tried using fmax in a test of my own and didn't find IPO causing a problem (nor did it help any; fmax was horribly slow in icc while in gcc it merely prevented vectorization). So the std:max() seems better for ICL.
0 Kudos
SergeyKostrov
Valued Contributor II
624 Views
In case if you don't use STL here are two more workarounds for consideration:

...
#ifndef CrtMax
#define CrtMax( ValueA, ValueB )( ( ValueA > ValueB ) ? ValueA : ValueB )
#endif
...

...
template < class T > inlineT Max2( T tValueA, T tValueB )
{
return ( T )( ( tValueA > tValueB ) ? tValueA : tValueB );
};
...
0 Kudos
Georg_Z_Intel
Employee
624 Views
Hello,

maybe I should add some words for clarification:

AFAIK functions fmax(...), fmin(...) & fmod(...) are affected; and only those coming from mathimf.h. Those are optimized versions from our compiler (intrinsics).
The IPO problem only exists on Windows*. On Linux* IPO will work correctly with those functions.

So a trivial and practical workaround would be to disable IPO for the compilation units using any of those problematic functions. Alternatively you can enable either of the Basic Runtime Checks options (/RTCs, /RTCu or /RTC1) for dedicated compilation units instead.
Another, yet impractical, workaround would be to replace the problematic functions by others; e.g. STL versions or own implementations, as proposed above. In some cases you might also use the C99 versions (math.h). However VS2010 does not implement all C99 functions yet (esp.: fmax(...) & fmin(...)).

There won't be a fix for any of the 12.1 update versions of the compiler. The next major compiler version will contain a fix for this.

Best regards,

Georg Zitzlsberger
0 Kudos
TimP
Honored Contributor III
624 Views
Replacing std:max with ? operator works well with icc (provided you don't have a macro with side effects), but doesn't vectorize with gcc.
0 Kudos
Reply