Bug 71918 - Internal compiler error: Illegal instruction
Summary: Internal compiler error: Illegal instruction
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 6.1.1
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-18 14:59 UTC by jordyruiz
Modified: 2016-07-19 07:39 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-07-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jordyruiz 2016-07-18 14:59:39 UTC
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.
------------------------
Comment 1 Markus Trippelsdorf 2016-07-18 15:06:53 UTC
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.)
Comment 2 jordyruiz 2016-07-18 15:34:27 UTC
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
Comment 3 Andrew Pinski 2016-07-18 15:36:19 UTC
(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 .
Comment 4 Andrew Pinski 2016-07-18 15:38:05 UTC
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.
Comment 5 Markus Trippelsdorf 2016-07-18 15:42:45 UTC
(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
Comment 6 jordyruiz 2016-07-18 15:50:31 UTC
> 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 ()
Comment 7 Markus Trippelsdorf 2016-07-18 15:55:38 UTC
It is as Andrew said: Your gmp library was compiled with BMI2 instructions
enabled (only available on Haswell and newer).

Not a gcc bug.
Comment 8 Andrew Pinski 2016-07-18 15:56:38 UTC
(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.
Comment 9 jordyruiz 2016-07-18 16:44:09 UTC
Alright then, thanks for the troubleshooting guys. Will be more careful when sharing libraries on different machines.
Comment 10 Jakub Jelinek 2016-07-19 06:58:26 UTC
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.).
Comment 11 Markus Trippelsdorf 2016-07-19 07:28:51 UTC
(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.
Comment 12 Jakub Jelinek 2016-07-19 07:39:13 UTC
(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.