LLVM ERROR: Unsupported integer vector type with numElems: 32, primitiveSize: 8!

[ricejasonf]

I'm getting this error during linking when using a function from the library libyuv.

I apologize for not being able to create a minimal test case. I'm not sure what causes it. It happens regardless of what optimization flags are set when I compile the library.

If it helps, the function that triggers it is here: https://github.com/lemenkov/libyuv/blob/master/source/convert_from.cc#L656

Is there a way to work around this? I am using 1.37.19.

Here is the full error output:

LLVM ERROR: Unsupported integer vector type with numElems: 32, primitiveSize: 8!
Traceback (most recent call last):
  File "/usr/local/src/emscripten/em++", line 16, in <module>
    emcc.run()
  File "/usr/local/src/emscripten/emcc.py", line 1515, in run
    final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
  File "/usr/local/src/emscripten/tools/shared.py", line 2020, in emscripten
    call_emscripten(cmdline)
  File "/usr/local/src/emscripten/emscripten.py", line 2214, in _main
    temp_files.run_and_clean(lambda: main(
  File "/usr/local/src/emscripten/tools/tempfiles.py", line 78, in run_and_clean
    return func()
  File "/usr/local/src/emscripten/emscripten.py", line 2219, in <lambda>
    DEBUG=DEBUG,
  File "/usr/local/src/emscripten/emscripten.py", line 2119, in main
    temp_files=temp_files, DEBUG=DEBUG)
  File "/usr/local/src/emscripten/emscripten.py", line 93, in emscript
    backend_output = compile_js(infile, settings, temp_files, DEBUG)
  File "/usr/local/src/emscripten/emscripten.py", line 122, in compile_js
    shared.jsrun.timeout_run(subprocess.Popen(backend_args, stdout=subprocess.PIPE), note_args=backend_args)
  File "/usr/local/src/emscripten/tools/jsrun.py", line 20, in timeout_run
    raise Exception('Subprocess "' + ' '.join(note_args) + '" failed with exit code ' + str(proc.returncode) + '!')

[kripken]

Did you build with SIMD support? If so, this could be an autovectorization bug. Otherwise, perhaps that function ends up including SIMD intrinsic using code, and a more general code path should be preferred?

[ricejasonf]

I tried -s SIMD=0 to no avail. not sure if that is supposed to do anything.

It appears to use the general C implementation, but I'll try forking the library to double check that it isn't somehow assuming the x86 code.

[kripken]

SIMD is off by default - you only need to use SIMD=1 flag to enable it (which is not recommended, at least until wasm properly standardizes SIMD and we support it - currently we're waiting on that before doing and SIMD work).

[ricejasonf]

Yes it was using an attribute to create that vector type here.

Thanks! :smiley: