https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #8 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #6)
> If the warning has false positives, then I'm sure the kernel will turn it
> off anyway like it does with tons of other warnings.
That is well possible. I try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #7 from Jeffrey A. Law ---
The thing is, if we could prove the trap is always executed, then we'd just zap
everything prior to the trap without visible side effects and everything after
the trap. It's actually not an interesting case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #6 from Jakub Jelinek ---
If the warning has false positives, then I'm sure the kernel will turn it off
anyway like it does with tons of other warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #5 from Marc Glisse ---
If we only warn when the trap is always executed as Arnd suggests (determined
in a similar way as uninitialized vs maybe-uninitialized), I guess there should
be fewer false positive (only cloning seems likely t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #4 from Jakub Jelinek ---
s/would be/would have/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #2 from Arnd Bergmann ---
(In reply to Richard Biener from comment #1)
> Note such warning in the middle-end has the chance of false
> positives from (for example) path isolation.
Would it be possible to warn if a function always tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
