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.

  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: link
Be 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).