Bug 5597 – [64-bit] Illegal Instruction on Ancient Hardware

The following code works on newer hardware, but terminates with "Illegal instruction" on some ancient CPUs (details below): import std.conv; void main() { string foo = "1.0"; parse!float(foo); } The ancient hardware in question (first CPU from cat /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) MP CPU 3.66GHz stepping : 1 cpu MHz : 3657.816 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl est tm2 cid cx16 xtpr bogomips : 7321.85 clflush size : 64 cache_alignment : 128 address sizes : 40 bits physical, 48 bits virtual power management:

BTW, I think this is related to the lahf instruction because it's apparently been a big problem in the past with old 64-bit CPUs not supporting it. Here's the cpuinfo for the oldest hardware this code does work on. The only difference in flags looks to be lahf. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E7330 @ 2.40GHz stepping : 11 cpu MHz : 2394.055 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow vnmi flexpriority bogomips : 4788.11 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:

Argh there really needs to be a way to edit these posts. I accidentally got the wrong box. The correct info for the oldest CPU it does work on is: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E7330 @ 2.40GHz stepping : 11 cpu MHz : 2393.892 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm bogomips : 4791.31 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:

When running it under gdb, can you verify that it actually does fail on the LAHF instruction?

Neither dmd nor the runtime uses LAHF, but they do use SAHF which I think is the same issue.

Looks like it does fail on sahf. I had a somewhat painful time, though, figuring this out. GDB just puts (bad) in the disassembly at that point (probably because the GDB on that machine is ancient). Therefore, I had to take the offset that the error was at and look for it in obj2asm.

This is a partial fix. I'll pick up the rest for the next release. cg87.c has more cases emitting SAHF, and Phobos1/Druntime/Phobos also use SAHF. https://github.com/D-Programming-Language/dmd/commit/6b787c45193675ed40f91e1b2edbe9c004b18d99 https://github.com/D-Programming-Language/dmd/commit/705b4fe1d798164d42da252c88bad0f5af201ee6

This was fully fixed in 2.053.