(C++) Getting error "Illegal instruction (core dumped)" upon bitwise OR operation

Question

So, I'm still learning about bitwise operations and can't figure out why this error is happening. I've googled it and it appears that this error can happen when messing with the stack, or, in some cases, it has to do with CPU architecture. I've tried compiling with different flags that were supposed to help but I can't get it to work.

Here's the the code quickly:

int corners = 0;
for (int i = 0; i < 8; i++)
{
    const ivec3 cornerPos = leaf->min + CHILD_MIN_OFFSETS[i];
    const float density = Density_Func(vec3(cornerPos));
    const int material = density < 0.f ? MATERIAL_SOLID : MATERIAL_AIR;
    corners |= (material << i);
}

And the error "Illegal instruction (core dumped)" is happening at the line

corners |= (material << i);

Here's the output from the debugger:

Signal received: SIGILL (Illegal instruction) For program, pid 26,118

I'm going to give the output of this loop (it never makes it past the first loop). Here's the code for the couts:

int corners = 0;
    std::cout<<"corners(outside loop): "<<corners<<std::endl;

for (int i = 0; i < 8; i++)
{
    const ivec3 cornerPos = leaf->min + CHILD_MIN_OFFSETS[i];
            std::cout<<"cornerPos.x: "<<cornerPos.x<<std::endl;
            std::cout<<"cornerPos.y: "<<cornerPos.y<<std::endl;
            std::cout<<"cornerPos.z: "<<cornerPos.z<<std::endl;

    const float density = Density_Func(vec3(cornerPos));
            std::cout<<"density: "<<density<<std::endl;

    const int material = density < 0.f ? MATERIAL_SOLID : MATERIAL_AIR;
            std::cout<<"material: "<<material<<std::endl;

            std::cout<<"MATERIAL_SOLID: "<<MATERIAL_SOLID<<std::endl;
            std::cout<<"MATERIAL_AIR: "<<MATERIAL_AIR<<std::endl;
            std::cout<<"i: "<<i<<std::endl;

    corners |= (material << i);
            std::cout<<"corners(inside loop): "<<corners<<std::endl;
}

and here's the output:

[corners(outside loop): 0] [cornerPos.x: -32] [cornerPos.y: -32] [cornerPos.z: -32] [density: -30] [material: 1] [MATERIAL_SOLID: 1] [MATERIAL_AIR: 0] [i: 0]

I would greatly appreciate any insight someone can give me about why this is happening, and if there is a clear reason, how to go about fixing the problem.

Thank you!

Solution

"Illegal instruction" means that CPU was trying to execute instruction which does not understand. This may happen if you compile your program with instruction set which is not supported by your CPU. Crash in this place may suggest that BMI2 bit shift instruction was used (it is supported on CPUs which supports also AVX2). Please check your compilation options.

Another possibility is that your program has overwritten some of its code. It is located at different memory area than stack, so things would be really messed up. I suspect this is not the case here.

This potentially can be also caused by overheating or some CPU bug, but these causes most probably can be excluded here too. The same for possible bug in compiler.

Comments

[Jabberwocky]

What is your platform (compiler versikon, OS, IDE)? Could you provide a minimal reproducible example?

[R Sahu]

It's unusual for a run time to have problems in a bitwise OR operation. Try to reduce the problem down to a minimal reproducible example and post it.

[Jabberwocky]

Also try to replace the call to Density_Func(vec3(cornerPos)); by somme dummy constant, just to see if the crashe still happens if Density_Func is not called.

[Klaus]

Have you ever tried to use a debugger? Is it really an illegal instruction emmited by the compiler or simply a illegal pointer access or stack problem? Your code contains so much functions which can do things we do not see. So lease provide a short example! I believe by doing this exercise your problem can be found by yourself...

[Bill Yan]

sometimes this could happen if you have a function that is supposed to return a value like (bool func()), but doesn't. It may crash at the beginning of the function and tell you Sigill. This seems to be seen only with clang+llvm, gcc doesn't seem to show this.