public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access
Date: Mon, 04 Mar 2024 08:35:38 +0000	[thread overview]
Message-ID: <bug-114217-4-mJSHlfZAUR@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114217-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Akihiko Odaki from comment #11)
> So there are two constructs invoking UBs but ignored by UBSan: 1)

That is an understatement. UBSan is a best effort which diagnoses some forms of
undefined behavior.  There are tons of undefined behavior UBSan doesn't catch,
most importantly e.g. aliasing violations, but far from limited to just that.
If a program is diagnostic free with -fsanitize=undefined,address , it doesn't
mean it is UB free, but the goal is that if there is diagnostic, there is a
real UB in the program.

You are basically asking for the PR80797 fix to be reverted just because you
aren't willing to fix UB in your code.  That is not going to happen, we've been
diagnosing this for almost 7 years now, I think clang even for 11 years, it is
a real UB and other projects have been able to cope with it.  By reverting the
change new UB in other programs couldn't be discovered.

  parent reply	other threads:[~2024-03-04  8:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-03  7:03 [Bug sanitizer/114217] New: " akihiko.odaki at daynix dot com
2024-03-03  7:10 ` [Bug sanitizer/114217] " pinskia at gcc dot gnu.org
2024-03-03  7:15 ` pinskia at gcc dot gnu.org
2024-03-03  7:19 ` akihiko.odaki at daynix dot com
2024-03-03  7:22 ` pinskia at gcc dot gnu.org
2024-03-03  7:29 ` akihiko.odaki at daynix dot com
2024-03-03  7:46 ` akihiko.odaki at daynix dot com
2024-03-03 19:01 ` jakub at gcc dot gnu.org
2024-03-04  5:26 ` akihiko.odaki at daynix dot com
2024-03-04  7:46 ` jakub at gcc dot gnu.org
2024-03-04  7:54 ` jakub at gcc dot gnu.org
2024-03-04  8:11 ` akihiko.odaki at daynix dot com
2024-03-04  8:35 ` jakub at gcc dot gnu.org [this message]
2024-03-04  8:45 ` akihiko.odaki at daynix dot com
2024-03-04 21:48 ` i at maskray dot me

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-114217-4-mJSHlfZAUR@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).