public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "uecker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow
Date: Sun, 11 Feb 2024 20:07:07 +0000	[thread overview]
Message-ID: <bug-113878-4-1rm3XN9v5Y@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113878-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878

--- Comment #8 from uecker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to uecker from comment #6)
> > My idea would be to explicitly add either traps or __builtin_unreachable
> > whenever there is UB that can be checked for in the C FE, and not add
> > sanitizer calls (that may return). Just a lightweight tool for safety that
> > needs no run-time and and be activated in production because it is optimized
> > well.
> 
> Something that traps is -fsanitize=undefined -fsanitize-trap=undefined (or
> selected sanitizers), that doesn't need any runtime.  And it is still very
> costly, it isn't lightweight, and it severely prevents optimizations.
> Something that would add conditional __builtin_unreachable would be useless,
> that is already implied from the operations.

Sure, but -fsanitize=undefined -fsanitize-trap=undefined does optimize much
worse than directly adding the overflow checks (as this and other examples
show) and also sometimes does not have quite the ideal semantics because of
upstream sanitizer library dependency. I wouldn't mind if it could be fixed but
its complexity seems to make it unnecessary hard.

  parent reply	other threads:[~2024-02-11 20:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-11 16:46 [Bug c/113878] New: " muecker at gwdg dot de
2024-02-11 16:55 ` [Bug sanitizer/113878] " pinskia at gcc dot gnu.org
2024-02-11 17:43 ` uecker at gcc dot gnu.org
2024-02-11 17:54 ` jakub at gcc dot gnu.org
2024-02-11 18:41 ` uecker at gcc dot gnu.org
2024-02-11 18:46 ` jakub at gcc dot gnu.org
2024-02-11 19:16 ` uecker at gcc dot gnu.org
2024-02-11 19:28 ` jakub at gcc dot gnu.org
2024-02-11 20:07 ` uecker at gcc dot gnu.org [this message]
2024-02-12  9:00 ` rguenth at gcc dot gnu.org

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-113878-4-1rm3XN9v5Y@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).