Intel build error: "Cannot match asm operand constraint"

[samuela]

Continuing discussion from https://groups.google.com/forum/#!topic/julia-users/pSeB8VwrW3A. Paraphrasing from the thread:

I'm on commit a318578. Running `make' gives me:

$ source /gpfs/runtime/opt/intel/2013.1.106/mkl/bin/mklvars.sh intel64 ilp64
$ export MKL_INTERFACE_LAYER=ILP64
$ make
    CC src/task.o
task.c(352): catastrophic error: Cannot match asm operand constraint
compilation aborted for task.c (code 1)
make[2]: *** [task.o] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2"

Make.user:

USEICC = 1
USEIFC = 1
USE_INTEL_MKL = 1
USE_INTEL_MKL_FFT = 1
USE_INTEL_LIBM = 1
JULIA_CPU_TARGET = core2

Weirdly, the exact same setup works fine compiling v0.3.

I'm trying to compile on a Linux machine with gcc 4.7.2 and MKL 11.1.1. I'm aware of #8294 but this seems like a distinct problem.

[samuela]

As Jameson suggested, I tried replacing "i"(start_task) with ""(&start_task) on line 357. The results:

$ make clean
$ make
    CC src/jltypes.o
    CC src/gf.o
    FLISP src/julia_flisp.boot
    FLISP src/julia_flisp.boot.inc
    CC src/ast.o
    CC src/builtins.o
    CC src/module.o
    CC src/codegen.o
    CC src/disasm.o
disasm.cpp(107): warning #858: type qualifier on return type is meaningless
      const char operator[] (const size_t idx) const { return Fptr[idx]; }
      ^

    CC src/debuginfo.o
    CC src/interpreter.o
    CC src/alloc.o
    CC src/dlload.o
    CC src/sys.o
    CC src/init.o
    CC src/task.o
/tmp/iccepE0QYas_.s: Assembler messages:
/tmp/iccepE0QYas_.s:813: Warning: indirect jmp without `*'
    CC src/array.o
    CC src/dump.o
...
    LINK usr/bin/julia
    JULIA usr/lib/julia/sys0.o
/gpfs/home/skainswo/julia-dev/usr/bin/julia: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /gpfs/home/skainswo/julia-dev/usr/bin/../lib/libjulia.so)
make[1]: *** [/gpfs/home/skainswo/julia-dev/usr/lib/julia/sys0.o] Error 1
make: *** [release] Error 2

So, it compiles with a warning but does not work entirely. How serious is the indirect jmp warning? Should I simply ignore it?

[tkelman]

sorry, nevermind I see you posted it early on

[vtjnash]

that probably means the assembly is wrong, and you won't be able to starts tasks. but, if you can get to a repl, then it is OK.

[samuela]

@vtjnash I'm still stuck on the GLIBCXX_3.4.15 error, so I can't get to a REPL unfortunately.

[vtjnash]

Did you do an OS upgrade recently? It seems to be complaining the the compiler (or some object file) is targeting a different version of libc than it is finding.

You could also just manually create an empty file there with the right name (sys0.so)

[samuela]

No, I don't think so.. I'm running on a cluster so things could have been upgraded behind the scenes. make cleanall && make still produces the error though.

[samuela]

I tried rebuilding on a clean clone. Got the same error.

[vtjnash]

i ask because having a compiler that is out of sync with the host OS is a typical cause of that error
(http://stackoverflow.com/questions/5216399/usr-lib-libstdc-so-6-version-glibcxx-3-4-15-not-found)

you also might try locate libstdc++.so.6 to see if/where that library exists on your system (the compiler probably has a local copy it used to link your code, but that library is perhaps no longer the version that exists as a symlink in any of the /usr/lib64 /usr/lib/ /usr/local/lib etc. folders

[samuela]

Hmm, well this is what locate libstdc++.so.6 gives me:

$ locate libstdc++.so.6
/usr/lib/libstdc++.so.6
/usr/lib/libstdc++.so.6.0.13
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo

I'm really baffled by this problem and I'm not sure exactly what to make of this output.

[samuela]

@vtjnash As you suspected, it looks like this is an issue with the way that gcc was configured on the cluster I'm using. I've figured it all out now.

Now I have:

$ ./julia 
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2533 (2015-01-06 19:27 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit a318578* (9 days old master)
|__/                   |  x86_64-unknown-linux-gnu


signal (11): Segmentation fault
ctx_switch at /gpfs/home/skainswo/julia-dev/src/task.c:352
Segmentation fault (core dumped)

So it looks like the "i"(start_task)/""(&start_task) replacement doesn't work.

[jiahao]

I got the same error building master with icc 14.0.1 on julia.mit. Removing the i from "i"(start_task) resulted in a successful build and basic things work in the REPL; however make test fails at the same place, which is what @vtjnash said would happen.

ᐅ  make test
    JULIA test/all

signal (11): Segmentation fault
ctx_switch at /home/jiahao/julia-intel/src/task.c:332
Segmentation fault (core dumped)

[tkelman]

Once we figure out how to fix this and get all tests passing with Intel compilers we really need to look into adding a buildbot for them. Maybe 2 buildbots, one Linux and one OSX.

[samuela]

As Tony mentioned in the Google group thread, is there any way we could get an Intel CI build? I think that would really help with these issues.

[tkelman]

That would be a very good idea. @staticfloat is our point person on setting up the buildbots (http://buildbot.e.ip.saba.us:8010/builders), that isn't quite as visible as the Travis and AppVeyor checkboxes on PR's but we have more control over the VM's there. @ViralBShah has been looking at the Intel license situation, which is still a little murky for non-Linux platforms.

edit: some past discussion at #8294 (comment)

[staticfloat]

Hrmmm. Interesting. I remember looking into icc builds a loooong time ago. @ViralBShah, if you want to shoot me instructions on how to install/configure icc on the buildbots, this shouldn't be too difficult.

[tkelman]

Apparently there's such a thing as an arch pkgbuild for the intel compilers? Surprised me to see, but possibly useful: https://github.com/jdtuck/intel-parallel-studio-xe/blob/master/PKGBUILD