Hello, I get this error on compiling. It's asking me to report a bug report. Is this of any interest? If so, what files would you need to troubleshoot this? Using gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC) Target: x86_64-redhat-linux Thanks. ------------------------ [ 1/24] [1] c++ src/cvc4/cvc4_smt.cpp [ 2/24] [2] c++ src/cvc4/cvc4_operand_visitor.cpp In file included from /home/***/system/include/cvc4/util/integer_gmp_imp.h:25:0, from /home/***/system/include/cvc4/util/integer.h:38, from /home/***/system/include/cvc4/util/cardinality.h:26, from /home/***/system/include/cvc4/expr/type.h:27, from /home/***/system/include/cvc4/expr/expr_manager.h:55, from src/cvc4/cvc4_operand_visitor.cpp:1: /usr/include/c++/6.1.1/limits:1598:7: internal compiler error: Illegal instruction min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; } ^~~ In file included from /home/***/system/include/cvc4/util/integer_gmp_imp.h:25:0, from /home/***/system/include/cvc4/util/integer.h:38, from /home/***/system/include/cvc4/util/cardinality.h:26, from /home/***/system/include/cvc4/expr/type.h:27, from /home/***/system/include/cvc4/util/uninterpreted_constant.h:21, from /home/***/system/include/cvc4/expr/expr.h:55, from /home/***/system/include/cvc4/expr/command.h:31, from src/cvc4/cvc4_smt.cpp:4: /usr/include/c++/6.1.1/limits:1598:7: internal compiler error: Illegal instruction min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; } ^~~ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. ------------------------
The preprocessed cvc4_operand_visitor.ii file. What processor do you use? Which illegal instruction do you hit? (Run gcc under gdb and look at the disassembly.)
Hi, I have managed to output a cvc4_operand_visitor.ii file, but it's 77182 lines long, I'm afraid this may not be what you're looking for. I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz. I ran gcc under gdb but I don't see any information about which illegal instruction was hit, sorry. Could you tell me how I could extract that info? Greetings
(In reply to jordyruiz from comment #2) > Hi, > > I have managed to output a cvc4_operand_visitor.ii file, but it's 77182 > lines long, I'm afraid this may not be what you're looking for. > > I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz. > > I ran gcc under gdb but I don't see any information about which illegal > instruction was hit, sorry. Could you tell me how I could extract that info? > Most likely you need to follow fork in gdb and then disassemble $pc,$pc+0x10 .
Also this is most likely GMP not compiled for generic but a specific CPU and you don't have a compatible CPU. Did you compile GMP yourself or did you get it from a distro? If you got it from a distro, you should report the bug to that distro.
(In reply to Andrew Pinski from comment #3) > (In reply to jordyruiz from comment #2) > > Hi, > > > > I have managed to output a cvc4_operand_visitor.ii file, but it's 77182 > > lines long, I'm afraid this may not be what you're looking for. > > > > I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz. > > > > I ran gcc under gdb but I don't see any information about which illegal > > instruction was hit, sorry. Could you tell me how I could extract that info? > > > > Most likely you need to follow fork in gdb and then disassemble $pc,$pc+0x10 > . Yes. set follow-fork-mode child run disass (and please also post the backtrace) bt
> Also this is most likely GMP not compiled for generic but a specific CPU and > you don't have a compatible CPU. > > Did you compile GMP yourself or did you get it from a distro? If you got it > from a distro, you should report the bug to that distro. I compiled GMP myself, on a different machine. So you probably found the cause of the issue. (In reply to Markus Trippelsdorf from comment #5) > > Yes. > > set follow-fork-mode child > run > disass > (and please also post the backtrace) > bt (gdb) disass Dump of assembler code for function __gmpn_mul_1: 0x00007ffff750b460 <+0>: push %rbx 0x00007ffff750b461 <+1>: push %rbp 0x00007ffff750b462 <+2>: push %r12 0x00007ffff750b464 <+4>: mov %rdx,%rbp 0x00007ffff750b467 <+7>: shr $0x2,%rbp 0x00007ffff750b46b <+11>: test $0x1,%dl 0x00007ffff750b46e <+14>: jne 0x7ffff750b4b6 <__gmpn_mul_1+86> 0x00007ffff750b470 <+16>: test $0x2,%dl 0x00007ffff750b473 <+19>: mov %rcx,%rdx 0x00007ffff750b476 <+22>: jne 0x7ffff750b492 <__gmpn_mul_1+50> 0x00007ffff750b478 <+24>: mulx (%rsi),%r9,%r8 0x00007ffff750b47d <+29>: mulx 0x8(%rsi),%r11,%r10 0x00007ffff750b483 <+35>: mulx 0x10(%rsi),%rcx,%r12 0x00007ffff750b489 <+41>: lea -0x20(%rdi),%rdi 0x00007ffff750b48d <+45>: jmpq 0x7ffff750b530 <__gmpn_mul_1+208> 0x00007ffff750b492 <+50>: mulx (%rsi),%rcx,%r12 0x00007ffff750b497 <+55>: mulx 0x8(%rsi),%rbx,%rax 0x00007ffff750b49d <+61>: lea -0x10(%rdi),%rdi 0x00007ffff750b4a1 <+65>: test %rbp,%rbp 0x00007ffff750b4a4 <+68>: je 0x7ffff750b550 <__gmpn_mul_1+240> 0x00007ffff750b4aa <+74>: mulx 0x10(%rsi),%r9,%r8 0x00007ffff750b4b0 <+80>: lea 0x10(%rsi),%rsi 0x00007ffff750b4b4 <+84>: jmp 0x7ffff750b516 <__gmpn_mul_1+182> 0x00007ffff750b4b6 <+86>: test $0x2,%dl 0x00007ffff750b4b9 <+89>: mov %rcx,%rdx 0x00007ffff750b4bc <+92>: jne 0x7ffff750b4dc <__gmpn_mul_1+124> => 0x00007ffff750b4be <+94>: mulx (%rsi),%rbx,%rax 0x00007ffff750b4c3 <+99>: lea -0x18(%rdi),%rdi 0x00007ffff750b4c7 <+103>: test %rbp,%rbp 0x00007ffff750b4ca <+106>: je 0x7ffff750b557 <__gmpn_mul_1+247> 0x00007ffff750b4d0 <+112>: mulx 0x8(%rsi),%r9,%r8 0x00007ffff750b4d6 <+118>: lea 0x8(%rsi),%rsi 0x00007ffff750b4da <+122>: jmp 0x7ffff750b51d <__gmpn_mul_1+189> 0x00007ffff750b4dc <+124>: mulx (%rsi),%r11,%r10 0x00007ffff750b4e1 <+129>: mulx 0x8(%rsi),%rcx,%r12 0x00007ffff750b4e7 <+135>: mulx 0x10(%rsi),%rbx,%rax 0x00007ffff750b4ed <+141>: lea -0x8(%rdi),%rdi 0x00007ffff750b4f1 <+145>: test %rbp,%rbp 0x00007ffff750b4f4 <+148>: je 0x7ffff750b549 <__gmpn_mul_1+233> 0x00007ffff750b4f6 <+150>: lea 0x18(%rsi),%rsi 0x00007ffff750b4fa <+154>: jmp 0x7ffff750b50a <__gmpn_mul_1+170> 0x00007ffff750b4fc <+156>: nopl 0x0(%rax) 0x00007ffff750b500 <+160>: lea 0x20(%rdi),%rdi 0x00007ffff750b504 <+164>: mov %r9,(%rdi) 0x00007ffff750b507 <+167>: adc %r8,%r11 0x00007ffff750b50a <+170>: mulx (%rsi),%r9,%r8 0x00007ffff750b50f <+175>: mov %r11,0x8(%rdi) 0x00007ffff750b513 <+179>: adc %r10,%rcx 0x00007ffff750b516 <+182>: mov %rcx,0x10(%rdi) 0x00007ffff750b51a <+186>: adc %r12,%rbx 0x00007ffff750b51d <+189>: mulx 0x8(%rsi),%r11,%r10 0x00007ffff750b523 <+195>: adc %rax,%r9 0x00007ffff750b526 <+198>: mulx 0x10(%rsi),%rcx,%r12 0x00007ffff750b52c <+204>: mov %rbx,0x18(%rdi) 0x00007ffff750b530 <+208>: mulx 0x18(%rsi),%rbx,%rax 0x00007ffff750b536 <+214>: lea 0x20(%rsi),%rsi 0x00007ffff750b53a <+218>: dec %rbp 0x00007ffff750b53d <+221>: jne 0x7ffff750b500 <__gmpn_mul_1+160> 0x00007ffff750b53f <+223>: lea 0x20(%rdi),%rdi 0x00007ffff750b543 <+227>: mov %r9,(%rdi) 0x00007ffff750b546 <+230>: adc %r8,%r11 0x00007ffff750b549 <+233>: mov %r11,0x8(%rdi) 0x00007ffff750b54d <+237>: adc %r10,%rcx 0x00007ffff750b550 <+240>: mov %rcx,0x10(%rdi) 0x00007ffff750b554 <+244>: adc %r12,%rbx 0x00007ffff750b557 <+247>: mov %rbx,0x18(%rdi) 0x00007ffff750b55b <+251>: adc $0x0,%rax 0x00007ffff750b55f <+255>: pop %r12 0x00007ffff750b561 <+257>: pop %rbp 0x00007ffff750b562 <+258>: pop %rbx ---Type <return> to continue, or q <return> to quit--- (gdb) bt #0 0x00007ffff750b4be in __gmpn_mul_1 () from /home/jruiz/.local/lib/libgmp.so.10 #1 0x00007fffffffd240 in ?? () #2 0x000000000000000a in ?? () #3 0x0000000000000061 in ?? () #4 0x00007ffff751687d in __gmpn_bc_set_str () from /home/jruiz/.local/lib/libgmp.so.10 #5 0x00007ffff7516ce7 in __gmpn_set_str () from /home/jruiz/.local/lib/libgmp.so.10 #6 0x00007ffff7798923 in parsed_string_to_mpfr () from /lib64/libmpfr.so.4 #7 0x00007ffff7799d9c in mpfr_strtofr () from /lib64/libmpfr.so.4 #8 0x000000000104a004 in real_from_string(real_value*, char const*) () #9 0x00000000013bc990 in real_from_string3(real_value*, char const*, format_helper) () #10 0x00000000013764d3 in ?? () #11 0x0000000000e5766e in c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) () #12 0x000000000134a113 in c_parse_file() () #13 0x0000000001377243 in c_common_parse_file() () #14 0x00000000013c41c8 in ?? () #15 0x0000000000d6059a in toplev::main(int, char**) () #16 0x0000000000d61d97 in main ()
It is as Andrew said: Your gmp library was compiled with BMI2 instructions enabled (only available on Haswell and newer). Not a gcc bug.
(In reply to jordyruiz from comment #6) > > Also this is most likely GMP not compiled for generic but a specific CPU and > > you don't have a compatible CPU. > > > > Did you compile GMP yourself or did you get it from a distro? If you got it > > from a distro, you should report the bug to that distro. > > I compiled GMP myself, on a different machine. So you probably found the > cause of the issue. If you don't disable the assembly code in GMP, GMP defaults to basically doing -march=native . You need to configure GMP correctly if you are going to use it across different machines which are different processor types.
Alright then, thanks for the troubleshooting guys. Will be more careful when sharing libraries on different machines.
Note that with GMP it isn't always just misconfigured GMP, see https://bugzilla.redhat.com/show_bug.cgi?id=1331943 seems some Skylake Pentium/Celeron chips report in cpuid BMI/BMI2 support which they don't have. So it is a question if -march=haswell or -march=skylake in GCC should include BMI/BMI2 or not (i.e. if users should treat their Haswell/Skylake Pentium/Celeron just as SandyBridge or IvyBridge, or if we need skylake vs. skylake-bmi etc.).
(In reply to Jakub Jelinek from comment #10) > Note that with GMP it isn't always just misconfigured GMP, see > https://bugzilla.redhat.com/show_bug.cgi?id=1331943 > seems some Skylake Pentium/Celeron chips report in cpuid BMI/BMI2 support > which they don't have. > So it is a question if -march=haswell or -march=skylake in GCC should > include BMI/BMI2 or not (i.e. if users should treat their Haswell/Skylake > Pentium/Celeron just as SandyBridge or IvyBridge, or if we need skylake vs. > skylake-bmi etc.). The issue can be fixed by a microcode/bios update. So it is clearly an Intel bug and I don't think anything should change for gcc.
(In reply to Markus Trippelsdorf from comment #11) > The issue can be fixed by a microcode/bios update. > So it is clearly an Intel bug and I don't think anything should change for > gcc. The wrong cpuid reporting sure. What I meant was that there are still CPUs that claim to be Haswell or Skylake, yet they don't support the ISAs GCC includes under the corresponding -march= option. Looking in detail on the Skylake based Pentium or Celeron, they don't even have AVX, so clearly users just must not consider them anything more than a mere westmere or something similar.