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

Intel C++ compiler 11.1.038 integrated to MSVC IDE IPO link phase internal error 0_1149

Marián__VooDooMan__M
New Contributor II
611 Views

Greetings,

Previous version had not this bug. When I compile with "debug" profile (w/o IPO phase), all is OK. When I turn on optimizations in "release" profile, multi-file IPO link phase ends with internal error:

--- snip ---
Linking... (Intel C++ Environment)
(0): internal error: 0_1149

xilink: error #10014: problem during multi-file optimization compilation (code 4)
xilink: error #10014: problem during multi-file optimization compilation (code 4)
--- snip ---

(see attach; NB: FFX 3.5.2 doesn't display it correctly, the latest Google Chrome and IE 8 is fine)

Best,
Marian
.

0 Kudos
1 Solution
Yuan_C_Intel
Employee
611 Views
Quoting - Marian

Greetings,

Yes I copy that replacing "/Ob2" by "/Ob0" helps both in test case and in my more complex program, though I get few warnings at link phase "ipo: warning #11020: unresolved ?..." each followed by " Referenced in ipo_61245obj.obj" (IPO's single-file object in link-time code generation).

Best,
Marian


Hi, Marian

Another work around is provided:
Using "/mGLOB_cg_lower_dllimport=F" to disable one new feature in 11.1 regarding the dll importcan work around the failure. You may have a try.

Thank you.

View solution in original post

0 Kudos
10 Replies
JenniferJ
Moderator
611 Views
Please try following:

1. Can you create a mylink.bat with the link cmd from build log? and run mylink.bat from the build env at the .vcproj folder?
See if you get the same error. This will help where the problem comes from: IDE integration or compiler linking.

2. if you get the same error, try to remove the /qipo options to see if it helps.

Jennifer
0 Kudos
Marián__VooDooMan__M
New Contributor II
611 Views

Greetings,

re #1: same error.
re #2: didn't help.

However, I found strange behavior. When I chaged in release profile option from /O3 (high-level optimization) to /Od (disable optimizations), I get 1 unresolved external error in few files. This error occurs only in release profile. I am able to reproduce this bug (see test case in attach + its build log).When using icc 11.0.072 it is all fine. However, I was unable to reproduce "internal error 0_1149" mentioned above by this test case. I suspect that internal error has nothing to do with IPO, but rather with this unresolved external.

EDIT: corrected English, corrected typos.

Marian
.

0 Kudos
Marián__VooDooMan__M
New Contributor II
611 Views

Greetings,

1. I worked around problem in test case by implementing overloaded "tos()" function for each numeric type used in code,

2. I worked around internal error by #include'ing instead of .

Best,
Marian
.

0 Kudos
Yuan_C_Intel
Employee
611 Views
Quoting - jsw7

Greetings,

re #1: same error.
re #2: didn't help.

However, I found strange behavior. When I chaged in release profile option from /O3 (high-level optimization) to /Od (disable optimizations), I get 1 unresolved external error in few files. This error occurs only in release profile. I am able to reproduce this bug (see test case in attach + its build log).When using icc 11.0.072 it is all fine. However, I was unable to reproduce "internal error 0_1149" mentioned above by this test case. I suspect that internal error has nothing to do with IPO, but rather with this unresolved external.

EDIT: corrected English, corrected typos.

Marian
.


Hi, jsw7
I tested your program in my local machine and reproduced the unresolved external error. Thiserror is due to the use of option /Qlong_double not compatible with Microsoft-provided library routines.

See description of option "/Qlong_double " in intel compiler documentation, you may find a note of the usage:

"Note that the Microsoft compiler and Microsoft-provided library routines (such as printf) do not provide support for 80-bit floating-point values. As a result, this option should only be used when referencing symbols within parts of your application built with this option or symbols in libraries that were built with this option."




0 Kudos
Marián__VooDooMan__M
New Contributor II
611 Views

Hi, jsw7
I tested your program in my local machine and reproduced the unresolved external error. Thiserror is due to the use of option /Qlong_double not compatible with Microsoft-provided library routines.

See description of option "/Qlong_double " in intel compiler documentation, you may find a note of the usage:

"Note that the Microsoft compiler and Microsoft-provided library routines (such as printf) do not provide support for 80-bit floating-point values. As a result, this option should only be used when referencing symbols within parts of your application built with this option or symbols in libraries that were built with this option."





Greetings,

Yes, I know that mixing up 8-byte-long "long double" and 16-byte-long one is asking for trouble, but I thought when I use 16-byte-long "long double" only internally, while casting it to 8-byte-long "double" when using enternally (e.g. printf, ,...) is okay. It should be. But I'm concerned about why even this code reproduces the problem:

--- snip ---
// compile with: /Qlong_double /Qpc80
int x=0;
cout << x;
--- snip ---

while this one is okay:

--- snip ---
// compile with: /Qlong_double /Qpc80
char x[]="hello";
cout << x;
--- snip ---

It looks like the compiler is generating template-specialized code for C++ streams for "long double" too, even if it is not used, and the linker gets mad about it.

Note, that this is no problem for version 11.0.072, this explores only in 11.1.038. Actually, while using version 11.0.072, and one breaks the rule of big NO-NO, or forget to cast "long double" to "double" before passing it to some external library, like pritnf, cout, or ostringstream, displayed number is messed-up, but linking problem doesn't come in.

I would be much happier if I could use "long double" only internally, while with ostringstream (or anything else) bycasting it to "double" first, as I'm used to with version 11.0.072.

Best,
Marian

0 Kudos
Yuan_C_Intel
Employee
611 Views
Quoting - Marian

Greetings,

Yes, I know that mixing up 8-byte-long "long double" and 16-byte-long one is asking for trouble, but I thought when I use 16-byte-long "long double" only internally, while casting it to 8-byte-long "double" when using enternally (e.g. printf, ,...) is okay. It should be. But I'm concerned about why even this code reproduces the problem:

--- snip ---
// compile with: /Qlong_double /Qpc80
int x=0;
cout << x;
--- snip ---

while this one is okay:

--- snip ---
// compile with: /Qlong_double /Qpc80
char x[]="hello";
cout << x;
--- snip ---

It looks like the compiler is generating template-specialized code for C++ streams for "long double" too, even if it is not used, and the linker gets mad about it.

Note, that this is no problem for version 11.0.072, this explores only in 11.1.038. Actually, while using version 11.0.072, and one breaks the rule of big NO-NO, or forget to cast "long double" to "double" before passing it to some external library, like pritnf, cout, or ostringstream, displayed number is messed-up, but linking problem doesn't come in.

I would be much happier if I could use "long double" only internally, while with ostringstream (or anything else) bycasting it to "double" first, as I'm used to with version 11.0.072.

Best,
Marian


Hi, Marian
Thank you for raising this issue. Yes,it looks like a regression from 11.0.

I checked the link fail is triggered by following options combination:
"/Ob1 /Qlong_double /MDd(MD)",
and the use ofnumbertocharacter conversion in C++ stream as described in the sample case.

I'll record this to our problem tracking system andlet you know whenwe have an update regarding it.

One walk-around could be to disable the inline function expansion by using "/Ob0". Could you have a try?

Thank you


0 Kudos
Marián__VooDooMan__M
New Contributor II
611 Views

Hi, Marian
Thank you for raising this issue. Yes,it looks like a regression from 11.0.

I checked the link fail is triggered by following options combination:
"/Ob1 /Qlong_double /MDd(MD)",
and the use ofnumbertocharacter conversion in C++ stream as described in the sample case.

I'll record this to our problem tracking system andlet you know whenwe have an update regarding it.

One walk-around could be to disable the inline function expansion by using "/Ob0". Could you have a try?

Thank you



Greetings,

Yes I copy that replacing "/Ob2" by "/Ob0" helps both in test case and in my more complex program, though I get few warnings at link phase "ipo: warning #11020: unresolved ?..." each followed by " Referenced in ipo_61245obj.obj" (IPO's single-file object in link-time code generation).

Best,
Marian

0 Kudos
Yuan_C_Intel
Employee
612 Views
Quoting - Marian

Greetings,

Yes I copy that replacing "/Ob2" by "/Ob0" helps both in test case and in my more complex program, though I get few warnings at link phase "ipo: warning #11020: unresolved ?..." each followed by " Referenced in ipo_61245obj.obj" (IPO's single-file object in link-time code generation).

Best,
Marian


Hi, Marian

Another work around is provided:
Using "/mGLOB_cg_lower_dllimport=F" to disable one new feature in 11.1 regarding the dll importcan work around the failure. You may have a try.

Thank you.
0 Kudos
Marián__VooDooMan__M
New Contributor II
611 Views

Hi, Marian

Another work around is provided:
Using "/mGLOB_cg_lower_dllimport=F" to disable one new feature in 11.1 regarding the dll importcan work around the failure. You may have a try.

Thank you.

Hi Yolanda,

unfortunately I see this problem again, after I switched to x64 bit compiler. It seems it is there only when release build (highly optimized) is adjusted to use few debugging features, like Microsoft's multit-htreaded debug DLL. Since my software needs to generate sound in real time, it is almost unusable with ordinary debug build without optimizations.

Regarding the switch you recommended: Yes! It helps. I'm looking forward for what it actually does.


I was googling around and found this article:
http://software.intel.com/en-us/articles/unresolved-external-symbol-error-at-link-phase-when-enabled-qlong_double/

saying:
Resolution Status:
This is a regression from C++ Compiler 11.0 regarding a new feature on 11.1:
"Thepost-11.0 handling of dllimport and inline, decides not to emit the funciton definition in this case, because it is expected to be supplied from the DLL. You can get the 11.0 and before behavior back by using /mGLOB_cg_lower_dllimport=F."


Thank you very much.
0 Kudos
Yuan_C_Intel
Employee
611 Views

Hi, Marian

I have verifiedthis issue is resolved in the Intel C++ Compiler Windows* Update 3, Update 4. You may download this compiler package from our Registration Center: https://registrationcenter.intel.com/.

Thank you.
0 Kudos
Reply