Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Bradley_K_
New Contributor I
335 Views

__intel_avx_rep_memset not defined

When running with gcc 4.8.3 headers installed, and icc 16.0.0, I get the the following error when using memset.  I'm running this on Fedora 20.  On Fedora 22, this error doesn't appear (possibly because that's gcc 5 headers, but I don't really know where the problem is comping from.

 

[bradley@30-87-232 intel]$ cat avxmemset.c
#include <string.h>

double v[1000];

int main() {
    memset(v, 0, sizeof(v));
    return 0;
}
[bradley@30-87-232 intel]$ icc --version
icc (ICC) 16.0.0 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[bradley@30-87-232 intel]$ gcc --version
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[bradley@30-87-232 intel]$ icc avxmemset.c -o avxmemset -O3 -std=c99 -xHost
/tmp/iccmz97Ff.o: In function `main':
avxmemset.c:(.text+0x3c): undefined reference to `__intel_avx_rep_memset'
[bradley@30-87-232 intel]$ 

 

0 Kudos
3 Replies
335 Views

Hi Bradley,

This issue should not be related to GCC headers, as this function is provided as part of Intel runtime library (libirc.so). It is a strange issue. Could you please try to debug as below?

1. Make sure your installation is correct and libirc.so is correct.

$ nm /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libirc.so | grep __intel_avx_rep_memset
0000000000038c80 T __intel_avx_rep_memset
$

This is where the function should be defined.

2. Confirm whether below works

$ icc avxmemset.c -lirc

Manually linking to libirc.so in command line.

Also, please confirm that your installation is in the default folder (/opt/intel)?

Thanks,

Shenghong

Bradley_K_
New Contributor I
335 Views

1) The library is present.

2) The compile with -lirc works with your proposed command line, but with the following it fails:

 

$ icc avxmemset.c -xHost -lirc

/tmp/iccik5nkD.o: In function `main':
avxmemset.c:(.text+0x3c): undefined reference to `__intel_avx_rep_memset'

But with the library path explicitly added it does work (don't need -lirc)

$ icc avxmemset.c   -xHost  -L/opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/

 

It appears that the problem is in LIBRARY_PATH

$ export LIBRARY_PATH=/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4
$ icc avxmemset.c   -xHost  
$ export LIBRARY_PATH=/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4::/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64
$ icc avxmemset.c   -xHost  
/tmp/icczMSpAW.o: In function `main':
avxmemset.c:(.text+0x3c): undefined reference to `__intel_avx_rep_memset'
$ export LIBRARY_PATH=/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4
$ icc avxmemset.c   -xHost  
/tmp/iccTpO5Y4.o: In function `main':
avxmemset.c:(.text+0x3c): undefined reference to `__intel_avx_rep_memset'

If the library path includes  the ...2013... then it fails (it doesn't matter whether the "old" path is first or second).  Also if I clear the LIBRARY_PATH completely, the compiler inserts the 2016 path anyway.

So the workaround for me is to clear the LIBRARY_PATH before invoking /opt/intel/compilervars.sh

I think this does indicate a bug in the compiler, however.  I invoked the compiler with -v to see what is going on and saw this:

$ export LIBRARY_PATH=/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4:/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64
$ icc avxmemset.c   -xHost  -v
...
ld    /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbegin.o --eh-frame-hdr --build-id -dynamic-linker /lib64/ld-linux-x86-64.so.2 -m elf_x86_64 -o a.out -L/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4 -L/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64 -L/opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64_lin -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/ -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/ -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ -L/opt/intel/compilers_and_libraries_2016.0.109/linux/tbb/lib/intel64/gcc4.4/ -L/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64/ -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../ -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib /tmp/iccuPlIJn.o -Bdynamic -Bstatic -limf -lsvml -lirng -Bdynamic -lm -Bstatic -lipgo -ldecimal --as-needed -Bdynamic -lcilkrts -lstdc++ --no-as-needed -lgcc -lgcc_s -Bstatic -lirc -lsvml -Bdynamic -lc -lgcc -lgcc_s -Bstatic -lirc_s -Bdynamic -ldl -lc /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o
/tmp/iccuPlIJn.o: In function `main':
avxmemset.c:(.text+0x3c): undefined reference to `__intel_avx_rep_memset'

And what I see is the compiler front end inserting the LD_LIBRARY_PATH (both the 2016 version and the 2013 version) as -L arguments.  The problem is that libirc.so is not in the LIBRARY_PATH exported by the 2016 version of compilervars.sh, but libirc.so *is* in the LIBRARY_PATH exported by the 2015 version of compilervars.sh.   So if you happen to have both paths in your LIBRARY_PATH, the compiler picks up the 2013 version of libirc.a, which doesn't have the function defined. 

 I was still a little confused by this bug since libirc.so isn't linked, but I think it is getting __intel_avx_rep_memset from libirc.a rather from the .so file.

I would probably consider this a bug in the interaction compilervars.sh, the compiler front end, and some library reorganization that happened between the 2013 version and the 2016 version.  The compiler is setting the -L arguments from its own internal ideas of what the LIBRARY_PATH should be, but it is also paying attention to LIBRARY_PATH. I'm not sure what the fix is, but it sure confused me.

I guess I would recommend that you include a note somewhere to the effect that the LIBRARY_PATH should be cleared of any previous values set by compilervars.sh.

335 Views

Hi Bradley,

Thank you very much for your detailed analysis and debug on the issue, and great that you can "fix" it by clear the environment.

I remember you mentioned "On Fedora 22, this error doesn't appear (possibly because that's gcc 5 headers, but I don't really know where the problem is comping from.", in fact, I tried with all the commands you mentioned above, and failed to reproduce the issue on Ubuntu system too. I guess this is really a strange corner case on Fedora 20 (I do not think it is related to gcc headers, as I've tested with several versions of GCC from 4.8 to 4.9, but I do not have gcc4.8.3 on my system!).

Whatever, I may need to install Fedora 20 and Intel compiler 2013 and 2016 on it, and see whether I can reproduce it. Clearing LIBRARY_PATH is possible, but that means to record all the LIBRARY_PATH we've used from old Intel compiler versions (which is a long list!), as we cannot clear all LIBRARY_PATH directly (sometimes, user may have some preset values in it). This may not be an easy thing for a script targeted to set environment. I'll try to reproduce and see what the root cause is. The LIBRARY_PATH may not be the real issue as it works on other systems like your Fedora 22, and my Ubuntu.

Thanks,

Shenghong

Reply