__intel_avx_rep_memset not defined

[Bradley_K_]

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]$ 

[Shenghong_G_Intel]

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_]

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.

[Shenghong_G_Intel]

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