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

ipo: error #11063

missing__zlw
Beginner
570 Views
I havea program that I can use icc (12.1.0e) compile with O3 option without any program.
In order to get more performance, I changed from -O3 to -fast, I got error :
ipo: error #11063: ../../../builds/libMylib1.a : MyClass::Func1()(_ZN20MyClass17Func1Ev) already defined in ../../../builds/libMyLib1.a

MyClass has more functions with Func1. I don't know why just Func1 causes problem.

I also tried to switch back to -O3 and added -ipo, same error. If I remove -ipo, it compiles fine.

Thanks. As my project is quite large, I can't provide the while source code.
0 Kudos
13 Replies
Georg_Z_Intel
Employee
570 Views
Hello,

just for my understanding: _ZN20MyClass17Func1Ev is not a valid mangled name.
Did you substitute the original class & function names before posting?
_ZN7MyClass5Func1Ev would be correct.

The option -fast is an alias for -xHOST -O3 -ipo -no-prec-div -static, and thus implies IPO.
Usually the GNU linker, which is used by Intel compiler, too, tolerates duplicate symbols to some extent. With IPO those can become real errors as you see because IPO needs to know the dependencies of symbols. Ambiguity locks out IPO.

You can easily find out what's currently about to be linked and use the tool nm to find the other occurrence of the duplicate symbol (besides libMyLib1.a).

My first guesses are: Either you have used the same name for a class & function (name clash) or you linked the same object to two libraries that are finally linked together.

Please let me know if you need further help.

Best regards,

Georg Zitzlsberger
0 Kudos
missing__zlw
Beginner
570 Views
You are right. I renames the class and function name as the original ones are long and meaningless to report.

I looked through my code and could not figure out. But I tried to remove the whole, now the compilation gives errors:

ipo: error #11021: unresolved pthread_setschedparam

Referenced in libZThread.a(ThreadOps.o)

I link both to pthread and ZThread library and there is no modification to these two library.

Thank you.

0 Kudos
TimP
Honored Contributor III
570 Views
Your reference to libpthread would need to come after the reference to libZthread.
0 Kudos
Georg_Z_Intel
Employee
570 Views
Hello,

if you see
ipo: error #11021: unresolved pthread_setschedparam

the pthread library was not included.

Can you make sure that the command line at exactly this link stage contains "-lpthread" and that there's no warning that this library cannot be found?

If it is there can you provide me the output of the compiler during linking by adding "-#" to the command line options? You can use a private reply so it's not publicly displayed.

Best regards,

Georg Zitzlsberger
0 Kudos
missing__zlw
Beginner
570 Views

I don't see the pthread error when I moved pthread lib after zthread lib. Thanks for the advice.
However, how I got new error:

ipo: error #11021: unresolved __builtin_isnan

Referenced in libO....

Also, it is SO slow to link with ipo option...

0 Kudos
Georg_Z_Intel
Employee
570 Views
Hello,

__builtin_isnan(...) is usually supported with 12.x compilers. I'm wondering which GCC environment you're using. 12.1 only supports up to 4.5. With 4.6 you might see problems like you described.
You can easily find out which GCC version compatibility is currently used:

$ icpc -v
icpc version 12.1.0 (gcc version 4.4.3 compatibility)


If you have multiple GCC environments installed you can specify one directly (e.g. --gcc-version=443 for GCC 4.4.3).

Regarding IPO:
Yes, the time to link increases significantly. The reason are the global optimizations that are very computation intensive.
During normal development it's better to not use IPO but enable it before a release (when you're going to run the tests/benchmarks).

Best regards,

Georg Zitzlsberger
0 Kudos
missing__zlw
Beginner
570 Views
I am using :
icc/12.1.0e/bin/icpc and I already specified :
-gcc-version=450 -cxxlib=/.../gcc/4.5.0

I also tried to set the env to the same gcc version, but the __builtin_isnan error persists.

Thanks.
0 Kudos
Georg_Z_Intel
Employee
570 Views
Hello,

fortunately I was able to reproduce this problem. It only occurs when you use IPO and std::isnan(...), like:
[cpp]#include 
#include 

int main(void) {
    std::cout << std::isnan(42.0) << std::endl;
    return 0;
}[/cpp]

$ icpc builtin.cpp -ipo
ipo: warning #11021: unresolved __builtin_isnan
Referenced in /tmp/ipo_icpcB4XMvu.o
ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_icpcB4XMvu.o


However, I'm getting a warning instead of an error. Maybe you have set the option -Werror, then this IPO warning turns into an error.
I filed a defect (DPD200271184) and let you know about the outcome.

Workarounds could be to use __builtin_isnan(...) instead or turn off -Werror and ignore the warning.

Best regards,

Georg Zitzlsberger
0 Kudos
SergeyKostrov
Valued Contributor II
570 Views
In my installation of GCC v3.4.2there are two headers with declaration of 'isnan' function:

In 'math.h' it is declared as follows:

...
_CRTIMP int __cdecl _isnan (double);
...

In 'cmath' it is declared as follows:

...
template
int
__capture_isnan(_Tp __f) { return isnan(__f); }

...
template
int
isnan(_Tp __f) { return __capture_isnan(__f); }

...

My main "suspect" is a'__capture_isnan' key wordbecause I couldn't find a declaration for it.I could
assume it is a wrapper around '__builtin_isnan'.

My question is:

What math-headers are you including in your codes? 'math.h' or 'cmath'?

Best regards,
Sergey
0 Kudos
Sukruth_H_Intel
Employee
570 Views
Hi Georg,
I checked it in ubuntu LTS 10.04 with

sukruth@sukruth-laptop:~/issues/T102393$ icpc -v

icpc version 12.1.2 (gcc version 4.4.3 compatibility)

Icompiled the same program used by you for reproducing the problem:- I was not emitted with any warnings and compilation was fine. The only chnage i made was using the std namespace. So just adding the "using namespace std;" emitted no warnings and later i checked it without using namespace and it emitted me with the same warning as of your case. So i was wondering how can including the namespace would remove the warnings?

Thanks,
Sukruth.H.V

0 Kudos
SergeyKostrov
Valued Contributor II
570 Views
...
So i was wondering how can including the namespace would remove the warnings?

Thanks,
Sukruth.H.V


Hi Sukruth,

Ithink that in these two cases, that ts without 'std' and with 'std', two different 'isnan' functions are
used.A non-template based andatemplate based.Because of this in a test case with namespace
declaration you didn't have a warning.

A verification could be done in a Debugger. Just step-into the 'isnan( ... )' call and you will see what function
is about to be executed.

Best regards,
Sergey

0 Kudos
SergeyKostrov
Valued Contributor II
570 Views

Here is another Test-Case for 'isnan' function:

#include

using namespace std;

void main( void )
{
int i;

i = isnan( ( float )42.0f );
i = isnan( ( double )42.0L );
i = isnan( ( long double )42.0L );

i = _isnan( ( float )42.0f );
i = _isnan( ( double )42.0L );
i = _isnan( ( long double )42.0L );

i = std::isnan( ( float )42.0f );
i = std::isnan( ( double )42.0L );
i = std::isnan( ( long double )42.0L );

i = std::isnan< float >( 42.0 );
i = std::isnan< double >( 42.0 );
i = std::isnan< long double >( 42.0 );
}

PS: There are compatibility issues between 'g++', Visual C++ and Borland C++ compilers but
'g++' v3.4.2 successfully compiled the Test-Case.

0 Kudos
Georg_Z_Intel
Employee
570 Views
Hello,

this defect will be fixed with Intel Composer XE 2011 Update 9.

Best regards,

Georg Zitzlsberger
0 Kudos
Reply