This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 13 Sep 2013 17:31:47 +0000
- Subject: [Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
- Auto-submitted: auto-generated
- References: <bug-58387-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #18)
> I'll also note that the plan for the isolated paths that exhibit undefined
> behaviour is to have them trap/abort at the statement which triggers the
> undefined behaviour.
Not even a -fif-it-is-undefined-I-deserve-what-I-get option (or
-fmy-program-will-not-abort which turns __builtin_abort into
__builtin_unreachable)? I understand that if I try to debug a program by adding
printf to check that this branch is not taken and it is taken but nothing is
printed, I'll be confused. But don't we lose a large part of the benefit by
only propagating the detection of undefined behavior forward (abort) and not
also backward (unreachable)?