undefined reference to `__svml_atanf4'

[gregfi04]

I'm issuing the following to compile a code, "dort":

ifort10 -O2 -traceback -vec-report0 -save -zero -xT -c ccstring.f

When it gets to the linking phase, I get the following:

dort.o: In function `pcon_.':
dort.f:(.text+0xa189): undefined reference to `__svml_atanf4'
dort.f:(.text+0xa222): undefined reference to `__svml_atanf4'
dort.f:(.text+0xa299): undefined reference to `__svml_atanf4'
dort.f:(.text+0xa50e): undefined reference to `__svml_cosf4'
dort.f:(.text+0xa6ab): undefined reference to `__svml_cosf4'
dort.f:(.text+0xa7c8): undefined reference to `__svml_cosf4'

The compile works fine if I use -O1. The issue is related to the optimization level at -xT. Is there any reason -xT shouldn't work with -O2? I'm using ifort version 10.1.017, 32-bit version.

[Steven_L_Intel1]

The compiler is optimizing with calls to the Short Vector Math Library. The ifort driver should be pulling in libsvml.a but perhaps it isn't - does adding -lsvml help?

[Ron_Green]

svml is the Short Vector Math Library, one of the files included in the /lib directory with the compiler. You can find those functions in libsvml.a. They are there. This contains vectorized transcendentals such as tan, sin, cos, etc.

O1 will not pull in the svml versions of these function calls. Only at O2 will the compiler try to bring these in instead of the non-vector versions.

What you have is the compiler cannot find libsvml.a in your /opt/intel/fc/10.1.017/lib dir (or whereever you installed the compiler). Check your LD_LIBRARY_PATH env var. Are you sourcing /opt/intel/fc/10.1.017/bin/ifortvars.sh (or .csh)?

And what is ifort10 - your own alias? Has this affected the default paths?

This is just an environment problem - make sure you source the appropriate ifortvars.sh (or .csh) file, and check your ifort10 alias as it could be the problem.

ron

[gregfi04]

LD_LIBRARY_PATH points to the right place, but I can't get the linker to work unless I specify "-lsvml". The contents of ifort10 are simply:

#!/bin/bash

PATH=/tools/intel/fc/10.1.017/bin:$PATH
export PATH

LD_LIBRARY_PATH=/tools/intel/fc/10.1.017/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

INTEL_LICENSE_FILE=/tools/intel/licenses
export INTEL_LICENSE_FILE

/tools/intel/fc/10.1.017/bin/ifort $*

[Ron_Green]

Ah, I think I see - you showed the compile line but not the link line. Are you using ifort as your link-driver or are you using ld? If ld, you will need to add in the appropriate Intel libraries that are needed.

ron

[gregfi04]

Right, I only showed the compile line. I'm using ifort10 (as showed in the previous post) as the linker.

[Ron_Green · Accepted solution]

OK, I think I've replicated what you are seeing. It will help next time to include compile and link lines via cut and paste along with a test program. here's what I'm doing to reproduce this:

rwgreen@spd16 ~]$ ./ifort10 -O2 -traceback -vec-report0 -c -save -xP dcostest.f90

[rwgreen@spd16 ~]$ ./ifort10 -O2 -traceback -vec-report0 -o dcostest dcostest.o

dcostest.o(.text+0xef): In function `MAIN__':

: undefined reference to `__svml_atan2'

dcostest.f90:

-----

program foo

real (kind=8) :: x(200) = 2.0

print*, 'cos is ', dcosd(x)

x = atan(x)

end program foo

---

BUT if I add -xT, -xP, -xW (whatever you want) to the ifort10 link phase, it will work:

[rwgreen@spd16 ~]$ ./ifort10 -O2 -traceback -vec-report0 -o dcostest -xP dcostest.o

[rwgreen@spd16 ~]$

The -x option on the link driver brings in the short vector math library.

One last point: -traceback is a great thing to add, BUT you will want to add "-g" to the compile/link options. Otherwise, you will NOT get symbolic function names in the tracebacks. -g, with our compiler, can be used with advanced optimization options such as O2 and O3. It mearly adds symbol info, it does NOT imply -O0. So please use -g anytime you use -traceback

I hope this helps.

ron

[gregfi04]

Ah, excellent. Thanks, Ron.

So, just to be clear, -g does not incur any significant performance penalties?

[TimP]

Quoting - gregfi04

So, just to be clear, -g does not incur any significant performance penalties?

No usual performance penalties, just increased size of executable.