public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced Date: Sat, 27 Jun 2020 15:36:46 +0000 [thread overview] Message-ID: <bug-95663-4-yAb6miy4o8@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-95663-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #13 from Jeffrey A. Law <law at redhat dot com> --- Marc, Yes, absolutely. In fact, I think that falls out of the work Martin S is doing in this space. Conceptually we're looking to generalize that code so that we can route more cases where the compiler detects undefined behavior through the path isolation routines. Within those commonized routines we want to have a knob which selects different behavior from the compiler when undefined behavior is detected which could potentially include issuing the RTL equivalent of __builtin_unreachable vs trap vs warn, but leave the code alone, try to mitigate, etc. Where I think we've differed in the past is what to do with conditional branch upon which the undefined behavior is control dependent upon. As you may remember, the original submission of path isolation would turn that conditional into an unconditional branch to the valid path. That's not correct because there can be observable behavior that occurs on the path from the conditional, but before the undefined behavior triggers. Having a knob to twiddle *that* may or may not be a good idea.
next prev parent reply other threads:[~2020-06-27 15:36 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-13 10:52 [Bug c++/95663] New: " jzwinck at gmail dot com 2020-06-15 6:47 ` [Bug tree-optimization/95663] " rguenth at gcc dot gnu.org 2020-06-15 10:04 ` redi at gcc dot gnu.org 2020-06-15 10:09 ` redi at gcc dot gnu.org 2020-06-15 11:46 ` jzwinck at gmail dot com 2020-06-15 12:50 ` rguenther at suse dot de 2020-06-15 12:53 ` redi at gcc dot gnu.org 2020-06-15 12:54 ` redi at gcc dot gnu.org 2020-06-15 13:03 ` rguenther at suse dot de 2020-06-15 13:32 ` jakub at gcc dot gnu.org 2020-06-26 22:18 ` law at redhat dot com 2020-06-27 0:20 ` jzwinck at gmail dot com 2020-06-27 11:49 ` glisse at gcc dot gnu.org 2020-06-27 15:36 ` law at redhat dot com [this message] 2020-06-27 15:40 ` law at redhat dot com 2020-06-27 15:57 ` jakub at gcc dot gnu.org 2021-01-07 13:13 ` redi at gcc dot gnu.org 2021-01-07 13:14 ` redi at gcc dot gnu.org 2021-01-07 20:00 ` law at redhat dot com 2021-12-13 11:05 ` hubicka at gcc dot gnu.org 2021-12-13 11:10 ` hubicka at gcc dot gnu.org 2021-12-13 15:51 ` law at gcc dot gnu.org 2022-01-03 9:54 ` rguenther at suse dot de
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-95663-4-yAb6miy4o8@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).