public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r11-10079] fold-const: Fix up -fsanitize=null in C++ [PR105729]
Date: Mon, 20 Jun 2022 06:37:37 +0000 (GMT)	[thread overview]
Message-ID: <20220620063737.9B6A9385828D@sourceware.org> (raw)

https://gcc.gnu.org/g:e396f501f8a33439dee3ee5eef5b1d3a928852d9

commit r11-10079-ge396f501f8a33439dee3ee5eef5b1d3a928852d9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri May 27 11:40:42 2022 +0200

    fold-const: Fix up -fsanitize=null in C++ [PR105729]
    
    The following testcase triggers a false positive UBSan binding a reference
    to null diagnostics.
    In the FE we instrument conversions from pointer to reference type
    to diagnose at runtime if the operand of such a conversion is 0.
    The problem is that a GENERIC folding folds
    ((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x)
    conversion to const struct Bar & by converting to that the first
    operand of the POINTER_PLUS_EXPR.  But that changes when the -fsanitize=null
    binding to reference runtime check occurs.  Without the optimization,
    it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
    call throws, that means it never triggers in the testcase.
    With the optimization, it checks whether this->data is NULL and it is.
    
    The following patch avoids that optimization during GENERIC folding when
    -fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
    REFERENCE_TYPE.
    
    2022-05-27  Jakub Jelinek  <jakub@redhat.com>
    
            PR sanitizer/105729
            * fold-const.c (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
            to (X &) z + w if -fsanitize=null during GENERIC folding.
    
            * g++.dg/ubsan/pr105729.C: New test.
    
    (cherry picked from commit e2f014fcefcd2ad56b31995329820bbd99072eae)

Diff:
---
 gcc/fold-const.c                      | 10 ++++++++++
 gcc/testsuite/g++.dg/ubsan/pr105729.C | 29 +++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 572d70b039d..8ce775753f3 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -9488,6 +9488,16 @@ fold_unary_loc (location_t loc, enum tree_code code, tree type, tree op0)
 		  > min_align_of_type (TREE_TYPE (TREE_TYPE (arg00)))))
 	    return NULL_TREE;
 
+	  /* Similarly, avoid this optimization in GENERIC for -fsanitize=null
+	     when type is a reference type and arg00's type is not,
+	     because arg00 could be validly nullptr and if arg01 doesn't return,
+	     we don't want false positive binding of reference to nullptr.  */
+	  if (TREE_CODE (type) == REFERENCE_TYPE
+	      && !in_gimple_form
+	      && sanitize_flags_p (SANITIZE_NULL)
+	      && TREE_CODE (TREE_TYPE (arg00)) != REFERENCE_TYPE)
+	    return NULL_TREE;
+
 	  arg00 = fold_convert_loc (loc, type, arg00);
 	  return fold_build_pointer_plus_loc (loc, arg00, arg01);
 	}
diff --git a/gcc/testsuite/g++.dg/ubsan/pr105729.C b/gcc/testsuite/g++.dg/ubsan/pr105729.C
new file mode 100644
index 00000000000..fb676630994
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ubsan/pr105729.C
@@ -0,0 +1,29 @@
+// PR sanitizer/105729
+// { dg-do run }
+// { dg-options "-fsanitize=null -fno-sanitize-recover=null" }
+
+int
+foo (int x)
+{
+  throw 0;
+}
+
+struct S {};
+struct T {
+  S *data;
+  T () : data (0) {}
+  const S &bar (int x) const { return data[foo (x)]; }
+};
+
+int
+main ()
+{
+  T t;
+  try
+    {
+      t.bar (-1);
+    }
+  catch (...)
+    {
+    }
+}


                 reply	other threads:[~2022-06-20  6:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220620063737.9B6A9385828D@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@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).