unresolved reference when -O3 is used

[Danesh_Daroui]

Hi all,

I have a problem during linking my code under Linux and Intel C++ 12.0. I can successfully link my code using this command:

icpc -O0 -ipo0 -fp-model precise -parallel -openmp -vec-report -par-report -openmp-report -DMKL_VML_MIXED /home/danesh/MUMPS_4.9.2/lib/libzmumps.a /home/danesh/MUMPS_4.9.2/lib/libmumps_common.a -L/home/danesh/metis-4.0.3/ -lmetis -L/home/danesh/MUMPS_4.9.2/PORD/lib/ -lpord -L/home/danesh/MUMPS_4.9.2/libseq -lmpiseq -liomp5 -lgfortran -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -o peec lproutines.o computation.o comp_wrapper.o util.o functions.o model.o parser.o solver.o peec.o integrationAPI.o subdivision.o matlabPlotter.o vtkPlotter.o incidentField.o FieldCalculator.o -lstdc++ -lpthread -lcxaguard -limf -lirc

Now when I change the optimization switch from "-O0" to "-O3" I get three unresolved references which are related to three function calls:

icpc -O3 -ipo0 -fp-model precise -parallel -openmp -vec-report -par-report -openmp-report -DMKL_VML_MIXED /home/danesh/MUMPS_4.9.2/lib/libzmumps.a /home/danesh/MUMPS_4.9.2/lib/libmumps_common.a -L/home/danesh/metis-4.0.3/ -lmetis -L/home/danesh/MUMPS_4.9.2/PORD/lib/ -lpord -L/home/danesh/MUMPS_4.9.2/libseq -lmpiseq -liomp5 -lgfortran -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -o peec lproutines.o computation.o comp_wrapper.o util.o functions.o model.o parser.o solver.o peec.o integrationAPI.o subdivision.o matlabPlotter.o vtkPlotter.o incidentField.o FieldCalculator.o -lstdc++ -lpthread -lcxaguard -limf -lirc
.
.
.
.
/tmp/ipo_icpcOvF5oK2.o: In function `SolverFDMNAND::solve()':
ipo_out2.c:(.text.hot0009f+0x45dd): undefined reference to `zmumps_c'
ipo_out2.c:(.text.hot0009f+0x4654): undefined reference to `zmumps_c'
ipo_out2.c:(.text.hot0009f+0x466a): undefined reference to `zmumps_c'

Does anybody know what the source of the problem can be? I googled a lot and found some similar problems that were related to inline suppression. I have also tested a small program and I could successfully compile using same switches without any problem.

Thanks for your help,

D.

[TimP]

Look for any error messages indicating that the compilation of that function failed at -O3.

[Danesh_Daroui]

Sorry but I don't get what you mean because the code is compiled successfully but at the linking I get those three "unresolved" error messages.

[mecej4]

You showed only the linker commands, so we do not know which functions are declared in which C or CPP source files.

There is little reason to specify -O3, etc. in a linking command and expect a significant speed increase, since there is nothing to compile unless IPO is involved.

However, when you choose to use IPO options in a linking command, the compiler driver may find that the input objects were not all compiled with IPO, and recompile as it thinks is necessary.

"Unsatisfied external" type errors are seen only at link time. With a good build system, one does not even attempt to link when the compilation of one or more input sources fails.

In the absence of that information, we may only speculate.

TimP's explanation is a good explanation, if it applies to what you have.

Often, code that I am developing has reached the point of running correctly, and I decide to prune out the diagnostic print statements and rebuild with a higher level of optimization. So, I change the source files and the makefile to put in the new options, and try to rebuild. One or more typos cause the rebuild to fail. I jump to the conclusion that the optimizer has a bug. I am wrong.

[Om_S_Intel]

You may try -ipo- compiler option. this will disable IPO.

Om

[Danesh_Daroui]

I tried with "-ipo-" but it didn't help.

Thanks,

D.

[mecej4]

Not in a command in which only objects are specified. The compiler driver would have no source files to compile and apply the -ipo- option to such compilations. If the object files had been compiled earlier with IPO requested, the net effect would be to turn on IPO even with the -ipo- option. Or am I missing an important point?

[Danesh_Daroui]

Well, yes I do compile all source file using "-ipo0" and "-O3" and then link them as I write again using these these two switches. It is very strange to me that changing to higher optimization level returns such error. I could compiler my code without absolutely any problem until I used this unresolved function. I compile each source file as:

icpc -DHAVE_CONFIG_H -I. -I/home/danesh/intel/mkl/include -I.. -I/home/danesh/MUMPS_4.9.2/libseq -I/home/danesh/MUMPS_4.9.2/include -I../include -DNOGMM_VERIFY -DUSE_OPENMP -O3 -ipo0 -fp-model precise -parallel -openmp -vec-report -par-report -openmp-report -DMKL_VML_MIXED -MT solver.o -MD -MP -MF .deps/solver.Tpo -c -o solver.o solver.cpp

I just tested a little bit more and I found out when I change the optimization lever to 1 or 2 (-O1 or -O2) new unresolved links come up:

ipo: warning #11021: unresolved matmul_mkl_
Referenced in libmetis.a(pmetis.o)
Referenced in libmetis.a(kmetis.o)
Referenced in libmetis.a(ometis.o)
Referenced in libmetis.a(meshpart.o)
Referenced in libmetis.a(mesh.o)
Referenced in libmetis.a(estmem.o)
Referenced in libmetis.a(mpmetis.o)
Referenced in libmetis.a(mkmetis.o)
Referenced in libmetis.a(kvmetis.o)
Referenced in libmetis.a(util.o)
Referenced in libmetis.a(graph.o)
Referenced in libmetis.a(coarsen.o)
Referenced in libmetis.a(initpart.o)
Referenced in libmetis.a(refine.o)
Referenced in libmetis.a(timing.o)
Referenced in libmetis.a(fortran.o)
Referenced in libmetis.a(kwayrefine.o)
Referenced in libmetis.a(stat.o)
Referenced in libmetis.a(separator.o)
Referenced in libmetis.a(mmd.o)
Referenced in libmetis.a(srefine.o)
Referenced in libmetis.a(compress.o)
Referenced in libmetis.a(mcoarsen.o)
Referenced in libmetis.a(minitpart.o)
Referenced in libmetis.a(mrefine.o)
Referenced in libmetis.a(minitpart2.o)
Referenced in libmetis.a(mrefine2.o)
Referenced in libmetis.a(mkwayrefine.o)
Referenced in libmetis.a(kwayvolrefine.o)
Referenced in libmetis.a(match.o)
Referenced in libmetis.a(balance.o)
Referenced in libmetis.a(fm.o)
Referenced in libmetis.a(sfm.o)
Referenced in libmetis.a(kwayfm.o)
Referenced in libmetis.a(subdomains.o)
Referenced in libmetis.a(debug.o)
Referenced in libmetis.a(kwayvolfm.o)
Referenced in libmetis.a(mincover.o)
Referenced in libmetis.a(myqsort.o)
Referenced in libmetis.a(mmatch.o)
Referenced in libmetis.a(pqueue.o)
Referenced in libmetis.a(mutil.o)
Referenced in libmetis.a(mfm.o)
Referenced in libmetis.a(mbalance.o)
Referenced in libmetis.a(mfm2.o)
Referenced in libmetis.a(mbalance2.o)
Referenced in libmetis.a(mkwayfmh.o)
Referenced in libmetis.a(ccgraph.o)
Referenced in libmetis.a(bucketsort.o)

if you check my previous post, I already have included all libraries for both METIS and MKL BLAS, so I am really confused why the linker doesn't find the appropriate library!

D.

[TimP]

We would suspect a problem in your link line, such as not observing the correct order for .a libraries (libmetis linked before MKL).

[Danesh_Daroui]

I changed the order but the problem exists. It means to me that when optimization flag is set in Intel C++ compiler, the order matters or something else happens, I am not sure. Because the code compiles successfully with -O0 flag. It is also interesting to know that I can compile a single file with exact sample link link commands without any problem. This is very strange to me! I could compile my code before without any problem with any flag set.

D.

[Mark_S_Intel1]

Were you able to resolve the problem?
You said you tried "-ipo-" . it's clear from the communication threads whether you compiled/linked without IPO. If you haven't already done so, please recompile and link without using -ipo. If you still see the unresolved errors, you could try to disable inlining of the routines in question (e.g. in case inlining is causing the errors) by using "__declspec(noinline)" right above the function definition:

__declspec(noinline)
int foo()
{ 
}

Thanks,
--mark

[TimP]

-fno-inline-functions would suppress all in-lining, in case the problem is associated with in-lining.

[Mark_S_Intel1]

Please try the inlining options suggested and let us know if the problem is resolved. I believe at this point we have explored all possible solutions without having a test case. To further investigate this issue we will need to have a test case if the previous suggestions don't help.

Thanks,
--mark