- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Best,
Marian
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page