[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:54 --- You should try out 4.3.1. Also this is not a good testcase, we need the preprocesed source that is producing the error with the exact command line that is used to compile that file. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #2 from vincent at vinc17 dot org 2008-06-10 09:09 --- (In reply to comment #1) You should try out 4.3.1. As I said, I could reproduce the problem with this version too (but there's a bug in gmp.h, so I was not sure). -- vincent at vinc17 dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-10 09:54 --- Waiting for a testcase. Also, can you show disassembly of the relevant region of code? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #4 from vincent at vinc17 dot org 2008-06-10 11:26 --- cmpb$42, -481(%rbp) je .L458 jmp .L456 .L463: cmpb$85, -481(%rbp) je .L461 cmpb$90, -481(%rbp) je .L462 jmp .L456 .L458: .loc 1 1845 0 addq$1, -336(%rbp) .loc 1 1846 0 .value 0x0b0f .L459: .loc 1 1849 0 addq$1, -336(%rbp) .loc 1 1850 0 movl$3, -224(%rbp) jmp .L455 I've just noticed the following warning: vasprintf.c:1846: warning: 'mpfr_rnd_t' is promoted to 'int' when passed through '...' vasprintf.c:1846: note: (so you should pass 'int' not 'mpfr_rnd_t' to 'va_arg') vasprintf.c:1846: note: if this code is reached, the program will abort I don't know if this is related, because the program dies with a SIGILL, not a SIGABRT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #5 from ubizjak at gmail dot com 2008-06-10 11:58 --- (In reply to comment #4) vasprintf.c:1846: note: (so you should pass 'int' not 'mpfr_rnd_t' to 'va_arg') vasprintf.c:1846: note: if this code is reached, the program will abort I don't know if this is related, because the program dies with a SIGILL, not a SIGABRT. This is correct, since __builtin_trap emits ud2 insn (0x0b0f) that generates SIGILL. Closed as INVALID. -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #6 from vincent at vinc17 dot org 2008-06-10 12:37 --- OK, but shouldn't g++ generate a SIGABRT instead of a illegal instruction? I've never had thought that a compiler should generate an illegal instruction on purpose, so making me think that the problem comes from the compiler. Also, is it a problem specific to g++ and is it invalid C++? gcc -std=c99 -Wc++-compat -pedantic -Wextra doesn't emit any warning about this code (but it was said that -Wc++-compat was incomplete). If this is specific to g++, then the SIGILL is not acceptable. Otherwise -Wc++-compat needs to be improved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #7 from ubizjak at gmail dot com 2008-06-10 13:33 ---
Here is a short explanation from config/i386/i386.md on this matter:
--cut here--
;; We used to use int $5, in honor of #BR which maps to interrupt vector 5.
;; That, however, is usually mapped by the OS to SIGSEGV, which is often
;; caught for use by garbage collectors and the like. Using an insn that
;; maps to SIGILL makes it more likely the program will rightfully die.
;; Keeping with tradition, 6 is in honor of #UD.
(define_insn trap
[(trap_if (const_int 1) (const_int 6))]
{ return ASM_SHORT 0x0b0f; }
[(set_attr length 2)])
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #8 from vincent at vinc17 dot org 2008-06-10 14:02 --- I agree about SIGSEGV. But what about abort()? Wouldn't this be cleaner? This builtin trap is quite similar to a failed assertion (often used to avoid undefined behavior), isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-10 14:38 --- Calling abort() doesn't work with free-standing environments. To answer the other questions we still need a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #10 from vincent at vinc17 dot org 2008-06-10 14:52 --- (In reply to comment #9) Calling abort() doesn't work with free-standing environments. OK, but how about using an illegal instruction with free-standing environments and abort() with hosted ones? After all, the abort() way is documented in the GCC manual (under __builtin_trap) and IMHO, abort() would provide a better QoI for hosted environments. Now, concerning the warning note: if this code is reached, the program will abort, could with __builtin_trap be added so that the user could look at the right place in the manual? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #11 from vincent at vinc17 dot org 2008-06-10 15:21 ---
Here's the testcase (I've never used va_list and so on myself, so I hope it is
correct; at least it shows the missing warning problem). With gcc -Wall
-std=c99 -Wc++-compat -pedantic -Wextra, I don't get any warning concerning the
incompatibility with C++.
#include stdlib.h
#include stdarg.h
typedef enum { ELEM = 17 } en_t;
void vafoo (int i, va_list ap1)
{
en_t x;
x = va_arg (ap1, en_t);
if (x != ELEM)
exit (1);
}
void foo (int i, ...)
{
va_list ap;
va_start (ap, i);
vafoo (i, ap);
va_end (ap);
}
int main ()
{
foo (0, ELEM);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
