Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

internal error: 0_2040


I'm getting the following error when trying to link object files together:

(0): internal error: 0_2040

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

Could anyone suggest what it means? Thanks!

0 Kudos
11 Replies

It means you've hit a bug in the compiler. The number 0_2040 is just a unique number to identify the assertion that was tripped (in this case it looks like it happened somewhere in the code generator).

If you can preprocess the file (using -E -P) and attach the resulting file along with any command line options needed to reproduce the problem then we can investigate and possibly offer a workaround.


Cool - I've just upgraded the compiler and already hit a bug :)

Unfortunately, I can't share the code; nor could I reproduce the error using some synthetic sources and similar compilation options.

All I can tell is that the compilation was done on a set of static libraries that were passed to the compiler as just object files to trigger IPO across them - if I just try to link them as static libraries, the compiler says that no IPO is going to be performed as there're no object files.

Some libraries have circular dependencies, therefore the static library list was surrounded by -Wl,--start-group ... -Wl,--end-group options to avoid errors from GCC (the same project is compiled with GCC as well).Looks likethese linker options trigger the error - if Iremove themfrom the icpc command line parameters list, icpc doesn't report any internal error (just complains about unresolved symbols).

Black Belt
If you're using the old compiler version which had a bug in the building of the linker script with the start-group ... end-group directive, you should upgrade to a version in which that bug was fixed.
I'm using 12.0.2.
Without a reproducer it is difficult to narrow down the issue.

You may diable IPO using -no-ipo or -ipo- compiler option as a workarround.
New Contributor I
If you have last compiler GNU compiler 4.6.0
build with flag -fwhole-program
if also false
build with flag -fwhole-program -flto
if always false
build with flag only -flto
if always false
use -fuse-plugin-linker -fuse-linker-plugin ... ... ... etc..
(-fuse-linker-plugin require you have recent or last libtool package installed)
for dissociate an determined element incriminated
If success result with only flags -fwhole-program.
you discover your program performance
largely largely improved, real difference..
If your program is large small chance it result build success only flags -fwhole-program,
also program large require minimum 2Go memory.
also do not use the flag make with --jobs=number
that would increase more the busy memory.
If you observe very long time for build, stop the process, large chance
It result halted error.
If you have are merged different library have mutiple origin compiler same with used
flag -fPIC Large chance that flto process resulting no success.

Frankly, I have never observed in my life an better compiler that this last
GNU compiler version.
An jewel rare ...
Unfortunately difficult to help you ICC side, now, long moment,
I not using this compiler also is well . (reason is only for compatibility (AIX)
IBM Power P and Z machine)
(GNU compiler 4.5.2 result build success AIX 5.1 probably also same with 4.6.0 ?)


Quoting Dmitri

All I can tell is that the compilation was done on a set of static libraries that were passed to the compiler as just object files to trigger IPO across them - if I just try to link them as static libraries, the compiler says that no IPO is going to be performed as there're no object files.

I might be missing something here, but just to clarify.

You have some static libs (let's call them libx.a and liby.a). These libraries were built with icpc with -ipo. You then try to do:

icpc -ipo libx.a liby.a

which doesn't work because icpc complains that they aren't valid objects, correct? I may misunderstand.

If so, you should be building the static libraries with xiar instead of ar. That will do the IPO over the objects in each library first - then you can use them in link steps. I don't know if it will help your internal error, but it might.

Otherwise, just start building some ofthe objects without -ipo, mix them with ones that were built with -ipo, and narrow down until you can find the (likely) two or three objects that cause the problem. Then you'll have a better workaround at least than disabling -ipo entirely, and it might be easier to come up with a test case.
New Contributor I
You have wrote
I might be missing something here
also for me, strange form (icpc -ipo libx.a liby.a) ???? i have never seen

Standard process for make static lib (Unix)
is :
(gcc) (g++) -c etc.....
ar r mynewlib.a object1.o object2.o object3.o object4.o object5.o etc...
ranlib mynewlib.a

Normally to add process ipo or lto it could be suposed resulting only one object.o (howto ...)

Now when you call library for your program you have not ipo relation regrouping object lib
only group objects that constitute your program source are concerned IPO process regroupment.

Supposed circular relation could be is only the new object using the lib function.
problem could be some common functions (inline call lib)

With 64 O/S require you use fPIC build lib but not sufficient.
Process IPO ,FLTO extremely complex you must accept probability possibility errors.
If you are interested this subject ,refer ltrans etc ...
Now this side too big, for my small old head and my too bad comprehension,
English language.

An test example with an personal source c++ to see change effect of length object..

I have make lib is (shared)

-rw-r--r-- 1 root root 7360 4 avril 02:55 obj_1.o
-rw-r--r-- 1 root root 12064 4 avril 02:55 obj_2.o
-rw-r--r-- 1 root root 6000 4 avril 02:55 obj_3.o
-rw-r--r-- 1 root root 11096 4 avril 02:55 obj_4.o
-rw-r--r-- 1 root root 7584 4 avril 02:55 obj_5.o

With -fwhole-program
(Success compile but result errors undefined reference when you call short alias lib (-lxx) )
( if alias name lib exist , is false is not working) require complete -L /usr/lib64/
when you call for It work correctly

-rw-r--r-- 1 root root 3216 4 avril 02:56 obj_1.o
-rw-r--r-- 1 root root 5680 4 avril 02:56 obj_2.o
-rw-r--r-- 1 root root 919 4 avril 02:56 obj_3.o
-rw-r--r-- 1 root root 4472 4 avril 02:56 obj_4.o
-rw-r--r-- 1 root root 5400 4 avril 02:56 obj_5.o

With -fwhole-program -flto (flto only same lenght)
-rw-r--r-- 1 root root 28592 4 avril 02:58 obj_1.o
-rw-r--r-- 1 root root 53800 4 avril 02:58 obj_2.o
-rw-r--r-- 1 root root 31064 4 avril 02:58 obj_3.o
-rw-r--r-- 1 root root 54912 4 avril 02:58 obj_4.o
-rw-r--r-- 1 root root 19312 4 avril 02:58 obj_5.o

With -flto-compression-level=9 -flto
-rw-r--r-- 1 root root 28504 4 avril 05:13 obj_1.o
-rw-r--r-- 1 root root 53672 4 avril 05:13 obj_2.o
-rw-r--r-- 1 root root 30984 4 avril 05:13 obj_3.o
-rw-r--r-- 1 root root 54752 4 avril 05:13 obj_4.o
-rw-r--r-- 1 root root 19312 4 avril 05:13 obj_5.o

All work ok and more speed.

Building the program with icc -ipo that call this lib borned origin GNU compiler with lto
work also perfectly.

Building all using icc compiler , program and library with ipo working perfectly.
xiar and xild comprise or not
work also perfectly
About circular relations i have doubt that existing more great quantize
My source lib test call an sub C backend lib Postgresql.

Intel Compiler..
With -fast (ipo included)
ipo: remark #11000: performing multi-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_iccmHHNFc.o

-rw-r--r-- 1 root root 44848 4 avril 13:19 obj1.o
-rw-r--r-- 1 root root 60016 4 avril 13:19 obj2.o
-rw-r--r-- 1 root root 50776 4 avril 13:19 obj3.o
-rw-r--r-- 1 root root 57088 4 avril 13:19 obj4.o
-rw-r--r-- 1 root root 38976 4 avril 13:19 obj5.o

with (-ipo only)
ipo: remark #11000: performing multi-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_iccbr3idx.o

-rw-r--r-- 1 root root 44784 4 avril 13:21 obj1.o
-rw-r--r-- 1 root root 59984 4 avril 13:21 obj2.o
-rw-r--r-- 1 root root 50768 4 avril 13:21 obj3.o
-rw-r--r-- 1 root root 57016 4 avril 13:21 obj4.o
-rw-r--r-- 1 root root 38928 4 avril 13:21 obj5.o

If I call lib to my program with -ipo -l (alias used)
all process working correct and program run well

If I call lib to my program with -fast
ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_iccLemGtf.o

ld: cannot find -l(alias)
with call complete -L/path/mylib

ipo: warning #11021: unresolved PQntuples
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQgetvalue
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQresultStatus
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQclear
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQerrorMessage
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQexec
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQstatus
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQconnectdb
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQsetdbLogin
Referenced in /tmp/ipo_iccroO8Wk.o
ipo: warning #11021: unresolved PQfinish

ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_iccroO8Wk.o
binary generated but Not working ....

Unresolved is not at my new lib, only with lib mother C implicated

Probably process compiler with ipo included in flag -fast obsolete with last libstd++ GNU
or is required I compile all Engine Database with ICC for It work
Just require time for search where is false....

xiar only each object can be dissociated under process
xild only the (gold linker) is paint Intel color to (elf_x86_64 elf_i386)
It could be automatically selected for me with last version libtool i have. (autoconf)



Without --start-group/--end-group options, compilers (both GCC and ICC)complains about certain symbols it can't find (since the libs have cross-dependencies as I mentioned). With these options, GCC works fine but ICC reports that internal error.

In the case of ICC, all libraries were compiled with -ipo and using xiar, so all the libraries are "valid".
Black Belt
According to what Brandon said, you tried to make .a libraries which included ipo .o files, but didn't use the special xiar tool, resulting in broken .a files. If you wish to use gnu ar directly, as Brandon said, you must remove the -ipo option for all .o files put in the library. The .o files made by icc -ipo aren't in a standard gnu format.
If your files were OK, and there were a bug in the icc treatment of start-group ... end-group, you would work around it by repeating the libraries with the circular dependencies.

In my reply to the Barndon's posting, I mentioned that I _did_ use xiar to produce .a files out of object files compiled with "-ipo".

As for the IPO,if I pass the librarieso the compiler through"-l...", icpc refuses to do any IPO saying that there're noobject files. Therefore, I have to pass ".a" files as just object files to icpc, which does trigger IPO at this stage but ends up with either complaints about unresolved symbols (if not using "--start/end-group"), or with that internal error (if using "--start/end-group").

Again, unfortunately, I tried to compose a synthetic test case with a few static libs with circular dependencies, but it workswithout that internal error.

I found a number of workarounds,justwondering what my be going wrong. Can it be something unrelated to IPO - like out of memory or disk space?

One more thing is- actually, I'm kind of surpised that if I do something like

icpc -ipo -static -lx -ly

instead of

icpc -ipo libx.a liby.a

no IPO is performed in the former case (saying "no objects specified for multi-file optimization"),even if libx.a and liby.a were made using "-ipo" and xiar. Is it something expected?