illegal hardware instruction (core dumped) on Intel Penryn CPU

[wingedrhino]

I have a laptop running an Intel T4400 (Core 2 architecture 45nm Penryn; SSE4 not natively supported as you can see here), Fedora 21 x86_64 and Node.js installed from the official repositories (currently v0.10.33).

Ran into a weird issue with gcloud-node which was traced to sse4_crc32.

Setup:

npm install sse4_crc32

Script

console.log('Importing sse4_crc32');
var SSE4CRC32 = require("sse4_crc32");
console.log('invoking sse4');
var output = SSE4CRC32.calculate("my string");
console.log('invoked sse4. output below');
console.log(output);
console.log('end');

Output

Importing sse4_crc32
invoking sse4
zsh: illegal hardware instruction (core dumped)  node require-test.js

[mranney]

Is it possible that the machine which compiled this module is different than the machine on which it is running?

[wingedrhino]

Nope. I did an npm install after manually removing the node_modules folder to ensure that the latest version of sse4_crc32 is used and compiled on my machine directly.

[mranney]

That's strange. It sounds like your compiler is generating code for your machine that won't actually run on your machine.

Internally, we use these compiler intrinsics here:

https://github.com/Voxer/sse4_crc32/blob/master/src/crc32c.c#L55

And we try to tell the compiler to do the right thing here:

https://github.com/Voxer/sse4_crc32/blob/master/binding.gyp#L14

But somehow, this isn't working for you. Could it be that your environment is inheriting some compiler flags that are not correct, but this is the first module for which it actually mattered?

It might be that there are other compiler flags we need to set in your environment to tell the compiler to generate valid code for your machine. Hopefully this is enough information for you to dig deeper into this and figure out what those flags are.

[wingedrhino]

Looking at https://github.com/Voxer/sse4_crc32/blob/master/binding.gyp#L14 it seems you are setting a compiler flag to explicitly enable SSE4.2. I'm not familiar with node-gyp but I suppose the cflags are simply passed on to GCC. My machine doesn't support SSE4.2 (nor do most pre-Nehalem CPUs I believe).

Looking at https://github.com/Voxer/sse4_crc32/blob/master/src/crc32c.c you seem to be using _mm_crc32_u64, _mm_crc32_u32, _mm_crc32_u16 and _mm_crc32_u8 all of which seem to be specific to SSE4.2 and thus the trouble.

I tried compiling with cflags set to -march=native (which applies the best possible cflags depending on how new the CPU is) and the compile failed. I'm pasting the relevant output of make debug below.

  CXX(target) Debug/obj.target/sse4_crc32/src/sse4_crc32.o
  CC(target) Debug/obj.target/sse4_crc32/src/crc32c.o
In file included from ../src/crc32c.c:13:0:
../src/crc32c.c: In function ‘calculateCRC32C’:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/smmintrin.h:827:1: error: inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option mismatch
 _mm_crc32_u8 (unsigned int __C, unsigned char __V)
 ^
../src/crc32c.c:47:13: error: called from here
         crc = _mm_crc32_u8(crc, *buf);
             ^
In file included from ../src/crc32c.c:13:0:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/smmintrin.h:846:1: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch
 _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
 ^
../src/crc32c.c:53:14: error: called from here
     CALC_CRC(_mm_crc32_u64, crc, uint64_t, buf, len);
              ^
../src/crc32c.c:23:21: note: in definition of macro ‘CALC_CRC’
             (crc) = op((crc), *(type *) (buf));                                                              \
                     ^
In file included from ../src/crc32c.c:13:0:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/smmintrin.h:839:1: error: inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific option mismatch
 _mm_crc32_u32 (unsigned int __C, unsigned int __V)
 ^
../src/crc32c.c:23:19: error: called from here
             (crc) = op((crc), *(type *) (buf));                                                              \
                   ^
../src/crc32c.c:55:5: note: in expansion of macro ‘CALC_CRC’
     CALC_CRC(_mm_crc32_u32, crc, uint32_t, buf, len);
     ^
In file included from ../src/crc32c.c:13:0:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/smmintrin.h:833:1: error: inlining failed in call to always_inline ‘_mm_crc32_u16’: target specific option mismatch
 _mm_crc32_u16 (unsigned int __C, unsigned short __V)
 ^
../src/crc32c.c:23:19: error: called from here
             (crc) = op((crc), *(type *) (buf));                                                              \
                   ^
../src/crc32c.c:56:5: note: in expansion of macro ‘CALC_CRC’
     CALC_CRC(_mm_crc32_u16, crc, uint16_t, buf, len);
     ^
In file included from ../src/crc32c.c:13:0:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/smmintrin.h:827:1: error: inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option mismatch
 _mm_crc32_u8 (unsigned int __C, unsigned char __V)
 ^
../src/crc32c.c:23:19: error: called from here
             (crc) = op((crc), *(type *) (buf));                                                              \
                   ^
../src/crc32c.c:57:5: note: in expansion of macro ‘CALC_CRC’
     CALC_CRC(_mm_crc32_u8, crc, uint8_t, buf, len);
     ^
make[1]: *** [Debug/obj.target/sse4_crc32/src/crc32c.o] Error 1
sse4_crc32.target.mk:88: recipe for target 'Debug/obj.target/sse4_crc32/src/crc32c.o' failed

There seems to be no fallback mechanism to provide an alternative if the CPU doesn't support SSE4.2. Could a code ask GCC to execute a different function on an older machine ?

BTW, to reproduce this error, you'll probably need to try out this code on a slightly older CPU which doesn't support SSE4.2. I'll recommend an Atom CPU seeing that most of the older ones don't support SSE 4.2.

[anandsuresh]

@mahtuag There are 2 issues at play here.

1. gcloud-node has a dependency on fast-crc32c by @ashi009 which implements a software fallback when no hardware acceleration is available. So on your non-SSE 4.2 platform, the fast-crc32c library should be using the software fallback option. Since you're still getting the build error, it seems that there may be an issue with the build chain wherein it is trying to compile this library on a platform that doesn't support hardware-accelerated CRC causing the build to crash, instead of not compiling this library or ignoring build errors for this library.
2. I've had a software-fallback implementation on my list of things to do for a while. Haven't yet had enough downtime from other projects to focus on adding it into the library just yet. Hopefully I'll get to it soon. In the meantime, if you're up for it, feel free to send me a PR for the fallback code and I'll merge it.

[ashi009]

TLDR. I don't think failed to build on non supporting platforms is a bug.
And it makes the project name worth its salt.

As software fallback within this package needs lots of work. Which is not
as simple as the npm's optional dependency mechanism.

On the other hand if you done it wrong, it would affect hardware
implementation performance. The earlier PR to add software fallback,
detects SSE4.2 support at every time calculate function being called.
On Fri, 6 Mar 2015 at 4:48 am Anand Suresh notifications@github.com wrote:

@mahtuag https://github.com/mahtuag There are 2 issues at play here.

gcloud-node has a dependency on fast-crc32c by @ashi009
https://github.com/ashi009 which implements a software fallback when
no hardware acceleration is available. So on your non-SSE 4.2 platform, the
fast-crc32c library should be using the software fallback option. Since
you're still getting the build error, it seems that there may be an issue
with the build chain wherein it is trying to compile this library on a
platform that doesn't support hardware-accelerated CRC causing the build to
crash, instead of not compiling this library or ignoring build errors for
this library.
2.

I've had a software-fallback implementation on my list of things to do
for a while. Haven't yet had enough downtime from other projects to focus
on adding it into the library just yet. Hopefully I'll get to it soon. In
the meantime, if you're up for it, feel free to send me a PR for the
fallback code and I'll merge it.

—
Reply to this email directly or view it on GitHub
https://github.com/Voxer/sse4_crc32/issues/20#issuecomment-77412468.

[anandsuresh]

@mahtuag Check out version 3.0.0 of the library. This version implements a fallback feature as well for older systems. Perhaps this can fix the issue you are seeing.

[anandsuresh]

Closing this. Please reopen if problem persists.

[noloader]

@ashi009:

TLDR. I don't think failed to build on non supporting platforms is a bug. And it makes the project name worth its salt.

For completeness, I ran into the issue on a SSE4.1 machine in my test environment. So I don't think its nullifying the project's name. The machine is a Core2 Duo, Debian 8.2, GCC 4.9 combination. It lacked SSE4.2 and String and Text New Instructions (STNI).

---

Here's the preprocessor dump of preprocessor macros of interest. If -march=native is omitted, then SSE3 and SSE4 do not make the list.

$ gcc -march=native -dM -E - </dev/null | sort | grep SSE
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSSE3__ 1

[anandsuresh]

@noloader Can you please re run the test with the latest version (v5.0.0)? It has been updated to better handle hardware-support detection.

[ashi009]

I will do this asap.
On Mon, Apr 25, 2016 at 11:01 PM Anand Suresh notifications@github.com
wrote:

Can you please re run the test with the latest version (v5.0.0)?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Voxer/sse4_crc32/issues/20#issuecomment-214305611