To reproduce the bug, get MPFR trunk, compile with CC=g++ (with or without
optimizations) and make check. The crash occurs on tprintf (and tsprintf and
tfprintf). I could reproduce it with both
  g++-4.2 (GCC) 4.2.4 (Debian 4.2.4-2)
  g++.real (Debian 4.3.1-1) 4.3.1

No problem with gcc.

(gdb) run
Starting program: /home/vlefevre/software/mpfr/tests/.libs/lt-tprintf

Program received signal SIGILL, Illegal instruction.
0x00007f65b27c5556 in __gmpfr_vasprintf (ptr=0x7fffbac424b0,
    fmt=0x404de4 "A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0)
    at vasprintf.c:1845
1845                  ++fmt;
Current language:  auto; currently c++
(gdb) bt
#0  0x00007f65b27c5556 in __gmpfr_vasprintf (ptr=0x7fffbac424b0,
    fmt=0x404de4 "A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0)
    at vasprintf.c:1845
#1  0x00007f65b27c1671 in __gmpfr_vprintf (
    fmt=0x404dde "a. %R*A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0)
    at printf.c:85
#2  0x00000000004028f4 in check_vprintf (
    fmt=0x404dde "a. %R*A, b. %Fe, c. %i%zn\n") at tprintf.c:67
#3  0x0000000000402c27 in check_mixed () at tprintf.c:192
#4  0x000000000040312b in main (argc=1, argv=0x7fffbac427d8) at tprintf.c:361

And with valgrind:

vin:...ftware/mpfr/tests> ./tprintf.vg
==19537== Memcheck, a memory error detector.
==19537== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==19537== Using LibVEX rev 1804, a library for dynamic binary translation.
==19537== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==19537== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
framework.
==19537== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==19537== For more details, rerun with: -v
==19537== 
vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0x48 0x83
==19537== valgrind: Unrecognised instruction at address 0x4E46556.
==19537== Your program just tried to execute an instruction that Valgrind
==19537== did not recognise.  There are two possible reasons for this.
==19537== 1. Your program has a bug and erroneously jumped to a non-code
==19537==    location.  If you are running Memcheck and you just saw a
==19537==    warning about a bad jump, it's probably your program's fault.
==19537== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19537==    i.e. it's Valgrind's fault.  If you think this is the case or
==19537==    you are not sure, please let us know and we'll try to fix it.
==19537== Either way, Valgrind will now raise a SIGILL signal which will
==19537== probably kill your program.
==19537== 
==19537== Process terminating with default action of signal 4 (SIGILL): dumping
core
==19537==  Illegal opcode at address 0x4E46556
==19537==    at 0x4E46556: __gmpfr_vasprintf (vasprintf.c:1845)
==19537==    by 0x4E42670: __gmpfr_vprintf (printf.c:85)
==19537==    by 0x4028F3: check_vprintf(char*, ...) (tprintf.c:67)
==19537==    by 0x402C26: check_mixed() (tprintf.c:192)
==19537==    by 0x40312A: main (tprintf.c:361)
==19537== 
==19537== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==19537== malloc/free: in use at exit: 6,832 bytes in 14 blocks.
==19537== malloc/free: 646 allocs, 632 frees, 390,447 bytes allocated.
==19537== For counts of detected errors, rerun with: -v
==19537== searching for pointers to 14 not-freed blocks.
==19537== checked 209,424 bytes.
==19537== 
==19537== LEAK SUMMARY:
==19537==    definitely lost: 0 bytes in 0 blocks.
==19537==      possibly lost: 0 bytes in 0 blocks.
==19537==    still reachable: 6,832 bytes in 14 blocks.
==19537==         suppressed: 0 bytes in 0 blocks.
==19537== Rerun with --leak-check=full to see details of leaked memory.
zsh: illegal hardware instruction  ./tprintf.vg


-- 
           Summary: g++ generates code with illegal instruction on Pentium D
                    / x86_64
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vincent at vinc17 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484

Reply via email to