This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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)


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)?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]