public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/108995] Missed signed integer overflow checks in UBsan? since r8-343-g2bf54d93f159210d
Date: Tue, 07 Mar 2023 07:54:48 +0000	[thread overview]
Message-ID: <bug-108995-4-JXvc9oOB0O@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108995-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We already fold this on GENERIC to

  *c = -229690488(OVF);

with optimization and

  *c = (int) b * 10921;

without.  It's almost surely through extract_muldiv, we also diagnose

t.c: In function ‘main’:
t.c:6:14: warning: integer overflow in expression ‘65526 * (int)b’ of type
‘int’ results in ‘-1378142932’ [-Woverflow]
    6 |   *c = 65526 * b / 6;
      |        ~~~~~~^~~

the issue seems to be that the C frontend, with optimization, constant folds
the
initializer of 'b' and with all-constants we ignore sanitization (but emit
a diagnostic).

Without optimization we run into extract_muldiv doing

      /* If these operations "cancel" each other, we have the main
         optimizations of this pass, which occur when either constant is a
         multiple of the other, in which case we replace this with either an
         operation or CODE or TCODE.

         If we have an unsigned type, we cannot do this since it will change
         the result if the original computation overflowed.  */
      if (TYPE_OVERFLOW_UNDEFINED (ctype)
          && ((code == MULT_EXPR && tcode == EXACT_DIV_EXPR)
              || (tcode == MULT_EXPR
                  && code != TRUNC_MOD_EXPR && code != CEIL_MOD_EXPR
                  && code != FLOOR_MOD_EXPR && code != ROUND_MOD_EXPR
                  && code != MULT_EXPR)))
        {

which is "fine".  We do have a few && !TYPE_OVERFLOW_SANITIZED checks
around but here we're missing it (I also believe we shouldn't do it this
way, but ...).

Without optimizing -Wstrict-overflow would diagnose this as well.

The following fixes the "bug" at -O0 but leaves the constant folding in the
frontend untouched (it could possibly refrain from replacing ops with
TREE_OVERFLOW constants when sanitizing overflow).

I'm not sure we want a patch like the following though.

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 9aaea71a2fc..a9af4dbd0a3 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -7102,6 +7102,8 @@ extract_muldiv_1 (tree t, tree c, enum tree_code code,
tree wide_type,
          if (wi::multiple_of_p (wi::to_wide (op1), wi::to_wide (c),
                                 TYPE_SIGN (type)))
            {
+             if (TYPE_OVERFLOW_SANITIZED (ctype))
+               return NULL_TREE;
              if (TYPE_OVERFLOW_UNDEFINED (ctype))
                *strict_overflow_p = true;
              return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
@@ -7112,6 +7114,8 @@ extract_muldiv_1 (tree t, tree c, enum tree_code code,
tree wide_type,
          else if (wi::multiple_of_p (wi::to_wide (c), wi::to_wide (op1),
                                      TYPE_SIGN (type)))
            {
+             if (TYPE_OVERFLOW_SANITIZED (ctype))
+               return NULL_TREE;
              if (TYPE_OVERFLOW_UNDEFINED (ctype))
                *strict_overflow_p = true;
              return fold_build2 (code, ctype, fold_convert (ctype, op0),

  parent reply	other threads:[~2023-03-07  7:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-02 19:00 [Bug sanitizer/108995] New: Missed signed integer overflow checks in UBsan? qrzhang at gatech dot edu
2023-03-06 12:42 ` [Bug sanitizer/108995] Missed signed integer overflow checks in UBsan? since r8-343-g2bf54d93f159210d marxin at gcc dot gnu.org
2023-03-07  7:54 ` rguenth at gcc dot gnu.org [this message]
2023-03-09 12:57 ` rguenth at gcc dot gnu.org
2023-03-09 13:29 ` cvs-commit at gcc dot gnu.org
2023-03-09 13:30 ` [Bug c/108995] " 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-108995-4-JXvc9oOB0O@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).