public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable
Date: Wed, 29 Jun 2022 19:26:33 +0200	[thread overview]
Message-ID: <YryLSXR/N63HQwlM@tucnak> (raw)
In-Reply-To: <162bc331-56a6-ed11-872a-658235611ce2@redhat.com>

On Wed, Jun 29, 2022 at 12:42:04PM -0400, Jason Merrill wrote:
> > The usual case is that people just use -fsanitize=undefined
> > and get both return and unreachable sanitization, for fall through
> > into end of functions returning non-void done through return sanitization.
> > 
> > In the rare case people use something different like
> > -fsanitize=undefined -fno-sanitize=return
> > or
> > -fsanitize=unreachable
> > etc., they presumably don't want the fall through from end of function
> > diagnosed at runtime.
> 
> I disagree with this assumption for the second case; it seems much more
> likely to me that the user just wasn't thinking about needing to also
> mention return.  Missing return is a logical subset of unreachable; if we
> sanitize all the other __builtin_unreachable introduced by the compiler, why
> in the world would we want to leave out this one that is such a frequent
> error?

UBSan was initially implemented in LLVM and our -fsanitize= options try to
match where possible what they do.
And their behavior is too that return and unreachable are separate
sanitizers, fallthrough from function return is sanitized only for the
former, they apparently at -O0 implement something like -funreachable-traps
(but not at -Og) and emit a trap there (regardless of
-fsanitize=unreachable), for -O1 and higher they act as if non-sanitized
__builtin_unreachable () is in there regardless of -fsanitize=unreachable.

It would be strange to diverge from this without a strong reason.
The fact that we use __builtin_unreachable for the function ends is just our
implementation detail and when we'd report that to users, they'd just be
confused on what's going on.  With -fsanitize=return they are told what
happens.

> Full -fsanitize=undefined is much higher overhead than just
> -fsanitize=unreachable, which introduces no extra checks.  And adding return
> checking to unreachable is essentially zero overhead.  I can't imagine any
> reason to want to check unreachable points EXCEPT for missing return.

-fsanitize=unreachable isn't zero overhead, it will force evaluation of all
the conditionals guarding it and preparation of arguments for it etc.

	Jakub


  reply	other threads:[~2022-06-29 17:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17 21:20 Jason Merrill
2022-06-20 11:05 ` Jakub Jelinek
2022-06-20 20:16   ` Jason Merrill
2022-06-22  4:04     ` Jason Merrill
2022-06-24 14:26       ` Jason Merrill
2022-06-27 15:44       ` Jakub Jelinek
2022-06-29 16:42         ` Jason Merrill
2022-06-29 17:26           ` Jakub Jelinek [this message]
2022-07-05 20:54             ` Jason Merrill

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=YryLSXR/N63HQwlM@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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).