[GR-70074] GraalVM 25 native-image executes BMI2 on Ivy Bridge (no bmi2), SIGILL at shlx despite -march=compatibility Environment:

[benname]

Describe the Issue

Environment:

• Build image: container-registry.oracle.com/graalvm/native-image:25-muslib
• Static musl build (Spring Boot 3.5.6 demo)
• Command uses -march=compatibility (also repros with -march=x86-64)
• GraalVM 24 works on the same target hosts

Target host:

• Intel Xeon E5-2695 v2 (Ivy Bridge) – no 'bmi2' in /proc/cpuinfo flags

Symptom:

• The binary starts, Tomcat initializes, then SIGILL.
• GDB shows SIGILL at RIP 0x2cdb685 executing shlx %rbx,%rax,%rax (BMI2), i.e. BMI2 path gets executed without a runtime CPU feature guard.
• AVX/AVX2 instructions do appear in the text segment (objdump), which could be fine if guarded; however the crash is caused by BMI2.

What I expect:

• With -march=compatibility or -march=x86-64, native-image should never execute BMI2/AVX2 on legacy x86_64.
• If higher-ISA fast paths are present, they must be protected by CPU feature checks.

What I tried:

• Also tried runtime flags to disable OpenSSL/Netty, issue still reproduces.
• The same app built with GraalVM 24 runs fine on the same machine.

Attachments:

• gdb-stdout.txt (shows RIP and shlx)
• sysinfo.txt (lscpu + /proc/cpuinfo first flags line; no 'bmi2')
• avx2-grep.txt and avx-bmi-grep.txt (objdump findings)
• crash-slice.s (objdump around the crashing address)
• r_client binary (stripped; available; can rebuild with -g if needed)
• gdb-session.log

Using the latest version of GraalVM can resolve many issues.

• I tried with the latest version of GraalVM.

GraalVM Version

25-graal

Operating System and Version

container-registry.oracle.com/graalvm/native-image:25-muslib

Troubleshooting Confirmation

• I tried the suggestions in the troubleshooting guide.

Run Command

./sigill-capture.sh ./r_client

Expected Behavior

Hope it works properly and meets compatibility standards

Actual Behavior

Illegal instruction

Steps to Reproduce

https://graalvm.slack.com/archives/CNBFR78F9/p1758773255930269?thread_ts=1758699452.515749&cid=CNBFR78F9

All compressed files have been included in this discussion

Additional Context

No response

Run-Time Log Output and Error Messages

2025-09-25T11:35:48.381+08:00 INFO 914482 --- [ main] com.semicons.github.OBApplication : Starting AOT-processed OBApplication v0.0.1-SNAPSHOT using Java 25 with PID 914482 (/root/test/r_client started by root in /root/test)
2025-09-25T11:35:48.382+08:00 INFO 914482 --- [ main] com.semicons.github.OBApplication : No active profile set, falling back to 1 default profile: "default"
2025-09-25T11:35:48.433+08:00 INFO 914482 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port 8080 (http)
2025-09-25T11:35:48.437+08:00 INFO 914482 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2025-09-25T11:35:48.437+08:00 INFO 914482 --- [ main] o.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/10.1.46]
Illegal instruction

[gergo-]

This seems to be an issue not with native-image but with running on this specific container. Some of the libraries in the container are built to target BMI2. In particular, the illegal instruction is in this snippet of code from libz.a:

    16f3:	0f 84 df 07 00 00    	je     1ed8 <inflate+0x1718>
    16f9:	41 0f b6 02          	movzbl (%r10),%eax
    16fd:	41 83 ec 01          	sub    $0x1,%r12d
    1701:	49 8d 4a 01          	lea    0x1(%r10),%rcx
    1705:	c4 e2 e1 f7 c0       	shlx   %rbx,%rax,%rax

This can be observed in the native-image:25-muslib image with: objdump -d /usr/local/musl/lib/libz.a | awk '/<inflate>:/{a=1} a; /^$/{a=0}' | grep -B4 shlx. This disassembles the file, uses awk to extract the disassembly for only the inflate function, then looks for occurrences of shlx with some preceding context.

The native image in the reproducer links to this library and then fails when the above instruction is executed on a non-BMI2 machine.

GraalVM 24 works on the same target hosts

Could you specify how you tried this? Did you run the same workload on the container-registry.oracle.com/graalvm/native-image:24-muslib container? It looks to me like it has a libz.a built in the same way, so I would expect it to fail in the same way.