digitalmars.D.bugs - [Issue 10054] New: x86_64 valgrind reports unrecognised instruction (DMD 2.062)
- d-bugmail puremagic.com (80/80) May 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10054
- d-bugmail puremagic.com (11/11) May 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10054
- d-bugmail puremagic.com (6/6) May 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10054
http://d.puremagic.com/issues/show_bug.cgi?id=10054 Summary: x86_64 valgrind reports unrecognised instruction (DMD 2.062) Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: estewh gmail.com Not sure if this is valgrind, me or DMD so thought I should report it. Program runs, so could be just valgrind. It causes valgrind grief when casting a mutable double variable to a ubyte variable. Casting a literal floating point value worked, as did an immutable double variable. ------------------------ void main() { double dval = 123.456; ubyte ubvalFAIL = cast(ubyte)(dval); // Causes the problem. ubyte ubvalOK = cast(ubyte)(123.456); // This cast works if above line commented out. } ------------------------ Given the second cast worked I tried the following and it worked also: void main() { immutable double dval = 123.456; ubyte ubvalOK = cast(ubyte)(dval); // Happy valgrind. } ============================================= $ objdump -d quicktest | grep "41652e" -n8 427- 41650c: f2 48 0f 10 05 ab 77 rex.W movsd 0x177ab(%rip),%xmm0 428- 416513: 01 00 429- 416515: f2 48 0f 11 45 f0 rex.W movsd %xmm0,-0x10(%rbp) 430- 41651b: dd 45 f0 fldl -0x10(%rbp) 431- 41651e: 50 push %rax 432- 41651f: d9 7c 24 02 fnstcw 0x2(%rsp) 433- 416523: 66 c7 44 24 04 bf 0f movw $0xfbf,0x4(%rsp) 434- 41652a: d9 6c 24 04 fldcw 0x4(%rsp) 435: 41652e: 48 df 1c 24 rex.W fistp (%rsp) <<<< HERE 436- 416532: 48 d9 6c 24 02 rex.W fldcw 0x2(%rsp) 437- 416537: 58 pop %rax 438- 416538: 88 45 f8 mov %al,-0x8(%rbp) 439- 41653b: 31 c0 xor %eax,%eax 440- 41653d: c9 leaveq 441- 41653e: c3 retq 442- 41653f: 90 nop 443- 416540: c8 00 00 00 enterq $0x0,$0x0 ============================================================================ VALGRIND OUTPUT (abbrev.) ------------------------ vex amd64->IR: unhandled instruction bytes: 0x48 0xDF 0x1C 0x24 0x48 0xD9 0x6C 0x24 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==2323== valgrind: Unrecognised instruction at address 0x4176fe. ==2323== at 0x4176FE: _Dmain (/tmp/quicktest.d:18) ... ... ==2323== Your program just tried to execute an instruction that Valgrind ==2323== did not recognise. There are two possible reasons for this. ==2323== 1. Your program has a bug and erroneously jumped to a non-code ==2323== location. If you are running Memcheck and you just saw a ==2323== warning about a bad jump, it's probably your program's fault. ==2323== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2323== i.e. it's Valgrind's fault. If you think this is the case or ==2323== you are not sure, please let us know and we'll try to fix it. ==2323== Either way, Valgrind will now raise a SIGILL signal which will ==2323== probably kill your program. =========================== Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10054 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim maxim-fomin.ru --- This is Valgrind issue. Some of x87 float instructions are not recognized by it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10054 Ok, thanks for looking into it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 10 2013