Created attachment 1152559 [details] preprocessed source Description of problem: As soon as g++ encounters a literal float expression (other than 1.0), an ICE occurs. Version-Release number of selected component (if applicable): gcc version 6.0.0 20160406 (Red Hat 6.0.0-0.20) How reproducible: Every time. Steps to Reproduce: 1. Upgrade F23 to F24 using dnf system-upgrade 2. g++ -o hello hello.cc Actual results: hello.cc:3:3: internal compiler error: Illegal instruction float x = 0.1; ^~~~~ Expected results: No ICE. ;) Additional info: hello.cc: int main() { float x = 0.1; } CPU is Intel(R) Pentium(R) CPU G4400 @ 3.30GHz (family: 0x6, model: 0x5e, stepping: 0x3).
gdb /usr/libexec/gcc/x86_64-redhat-linux/6.0.0/cc1plus GNU gdb (GDB) Fedora 7.11-66.fc24 [...] (gdb) r hello.cc Starting program: /usr/libexec/gcc/x86_64-redhat-linux/6.0.0/cc1plus hello.cc Program received signal SIGILL, Illegal instruction. 0x00007ffff7501514 in __gmpn_submul_1_coreihwl () at tmp-coreihwl_submul_1.s:165 165 jmp .Llo3 (gdb) bt full #0 0x00007ffff7501514 in __gmpn_submul_1_coreihwl () at tmp-coreihwl_submul_1.s:165 No locals. #1 0xa000000000000000 in ?? () No symbol table info available. #2 0x0000000000000000 in ?? () No symbol table info available. (gdb)
Still reproducible with gcc-c++-6.1.1-2.fc24.x86_64.rpm (gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)).
The backtrace clearly shows it doesn't have anything to do with gcc, but gmp.
Created attachment 1157095 [details] gnome-calculator stacktrace I noticed another program that exhibits a SIGILL, gnome-calculator. The stacktrace also seems to originate from gmp. I've attached it here. My system has gmp-6.1.0-2.fc24.x86_64 and gnome-calculator-3.20.1-1.fc24.x86_64.
I can not reproduce the crash. Looking at your backtrace, why would a jmp be invalid instruction? Build log seems like the file is compiled in a quite usual way: gcc -c -Wa,--noexecstack -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_coreihwl_submul_1 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wa,--noexecstack tmp-coreihwl_submul_1.s -fPIC -DPIC -o .libs/coreihwl_submul_1.o Jakub, could you please give me a hint what might be happening here? Could it be a bug in gcc after all, producing bad code from a good assembly source?
Created attachment 1162007 [details] preprocessed assembler source code from gmp According to the report, the crash happens on line 165 in this file.
I can't reproduce it either, bet (if it is reproduceable at all anywhere) the same kind of CPU. Does gmp choose at runtime different routines based on CPUID etc? What ISA does __gmpn_submul_1_coreihwl need? The above mentioned CPU is likely: http://ark.intel.com/products/88179/Intel-Pentium-Processor-G4400-3M-Cache-3_30-GHz Looking at that function, I see: 3a514: c4 62 b3 f6 06 mulx (%rsi),%r9,%r8 3a519: c4 62 a3 f6 56 08 mulx 0x8(%rsi),%r11,%r10 MULX is a BMI2 instruction, G4400 is Skylake based chip. Can we ask for /proc/cpuinfo content?
https://software.intel.com/en-us/forums/intel-isa-extensions/topic/584240 suggests that not all Skylake CPUs and not all Haswell CPUs do support BMI/BMI2, in particular i3 and above do and Pentium/Celeron don't. So guess either gmp needs to look more carefully at models, or check also the ISA bits before it decides to use particular optimized implementation.
Also see http://www.realworldtech.com/forum/?threadid=152533&curpostid=152533 , clearly some CPUs even report it incorrectly in CPUID that they do support even when they don't.
So the problem is the instruction right AFTER the jump, not the jump itself. I misunderstood that, thank you very much. Yes, gmp can choose between routines at runtime and this feature was recently enabled in Fedora.
I contacted the upstream and they asked to test the latest snapshot from https://gmplib.org/download/snapshot/ I still could not find a machine to reproduce the bug. Can you try it? Do you need me to prepare an rpm for you?
(In reply to Jakub Jelinek from comment #7) > Can we ask for /proc/cpuinfo content? processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Pentium(R) CPU G4400 @ 3.30GHz stepping : 3 microcode : 0x7c cpu MHz : 799.992 cache size : 3072 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust erms invpcid rdseed smap clflushopt xsaveopt xsavec xgetbv1 dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp bugs : bogomips : 6624.17 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Pentium(R) CPU G4400 @ 3.30GHz stepping : 3 microcode : 0x7c cpu MHz : 799.992 cache size : 3072 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 22 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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust erms invpcid rdseed smap clflushopt xsaveopt xsavec xgetbv1 dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp bugs : bogomips : 6624.17 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
(In reply to Frantisek Kluknavsky from comment #11) > I contacted the upstream and they asked to test the latest snapshot from > https://gmplib.org/download/snapshot/ > I still could not find a machine to reproduce the bug. Can you try it? Do > you need me to prepare an rpm for you? Yes please, or at least a srpm and/or spec file.
Created attachment 1163178 [details] latest gmp srpm
Created attachment 1163179 [details] latest gmp binary rpm
I can confirm that the snapshot RPM resolves the issue (for both GCC and gnome-calculator).
I would rather wait for a regular release and not rebase to a daily snapshot if it concerns only a minor fraction of machines.
Gmp 6.1.1 is in Fedora 24 for some time already. Closing as ERRATA. If problems persist, feel free to reopen this bug.