https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d68d366425369649cb4e25a07752e25a4fff52cf
commit r13-1204-gd68d366425369649cb4e25a07752e25a4fff52cf
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #5 from Jason Merrill ---
The suggested -funreachable-traps seems to have a lot of overlap with
-fsanitize-undefined-trap-on-error; I wonder about combining them, and having
it by itself imply -fsanitize=unreachable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #4 from Jonathan Wakely ---
PR 104884 is another "why is undefined behaviour so surprising?" case for
-funreachable-traps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> Not sure, people will still see the surprising behavior at -O1+ then
Sure, but we can justify that as optimizing away the checks. But giving a
predictable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #1 from Richard Biener ---
Not sure, people will still see the surprising behavior at -O1+ then and at -O0
we're not exploiting the __builtin_unreachable () in too surprising ways (we'll
just fall thru to the next function or so -
