[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2025-01-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

--- Comment #6 from Andrew Pinski  ---
(In reply to Hans-Peter Nilsson from comment #5)
> (In reply to Andrew Pinski from comment #0)
> > As mentioned a few times -ftrapv is broken in many cases it would be better
> > if it become something like -fsanitize=undefined
> > -fsanitize-undefined-trap-on-error.
> 
> Wouldn't that require sanitizer support for the target?

In the case of `-fsanitize-undefined-trap-on-error` does not require any
sanitizer support as what was a sanitizer call just becomes a __builtin_trap
call. It does require the target to have support for the trap optab or the
support for the abort call but I think that is currently supported for all
targets right now. The trap optab would definitely improve things if not
already supported on the target too.

[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2025-01-19 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #0)
> As mentioned a few times -ftrapv is broken in many cases it would be better
> if it become something like -fsanitize=undefined
> -fsanitize-undefined-trap-on-error.

Wouldn't that require sanitizer support for the target?

[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2021-08-15 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||78473

--- Comment #4 from Andrew Pinski  ---
the request for a division overflow function is PR 78473.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78473
[Bug 78473] Enhancement request:  __builtin_div_overflow

[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2021-08-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

Andrew Pinski  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 94934 has been marked as a duplicate of this bug. ***

[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2021-07-20 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Note, -fsanitize=undefined -fsanitize-undefined-trap-on-error actually doesn't
use IFN_{ADD,SUB,MUL}_OVERFLOW, those are used for the __builtin_*_overflow*
builtins, but its own IFN_UBSAN_CHECK_{ADD,SUB,MUL} ones.
Those are for the IL simpler than IFN_{ADD,SUB,MUL}_OVERFLOW, they just return
their value instead of _Complex containing both the value and overflow flag -
the abort operation (whether __builtin_trap () or some libubsan API call) is
implicit in it.
I think best would be to introduce for -ftrapv another set of ifns, and treat
those mostly as IFN_UBSAN_CHECK_{ADD,SUB,MUL}, except that the abort operation
would be always __builtin_trap regardless of
-f{,no-}sanitize-undefined-trap-on-error and perhaps the expansion could at
least for -Os or for longer sequences try to use the existing libgcc APIs when
they are available.
Negate is for ubsan handled as IFN_UBSAN_CHECK_SUB (0, x), yes, division would
need a new ifn.

[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error

2021-07-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  In particular this would free the compiler from caring about
-ftrapv when generating expressions on its own.  It was suggested that this
transform can be done at gimplification time using the
IFN_{ADD,SUB,MUL}_OVERFLOW machinery
(notably negate and division are missing here but easy to test for).