public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tim Lange <mail@tim-lange.me>
To: dmalcolm@redhat.com
Cc: gcc-patches@gcc.gnu.org, Tim Lange <mail@tim-lange.me>
Subject: Re: [PATCH] analyzer: consider empty ranges and zero byte accesses [PR106845]
Date: Sun, 11 Sep 2022 14:08:56 +0200	[thread overview]
Message-ID: <20220911120856.38550-1-mail@tim-lange.me> (raw)
In-Reply-To: <359c4cd9b3afcaffd974883847073bc41aae3e4e.camel@redhat.com>

> ...it took me a moment to realize that the analyzer "sees" that this is
> "main", and thus buf_size is 0.
> 
> Interestingly, if I rename it to not be "main" (and thus buf_size could
> be non-zero), we still don't complain:
>   https://godbolt.org/z/PezfTo9Mz
> Presumably this is a known limitation of the symbolic bounds checking?

Yeah. I do only try structural equality for binaryop_svalues.  The
example does result in a call to eval_condition_without_cm with two
  unaryop_svalue(NOP_EXPR, initial_svalue ('buf_size'))
that have different types ('unsigned int' and 'sizetype').  Thus,
lhs == rhs is false and eval_condition_without_cm does return UNKNOWN.

Changing the type of buf_size to size_t removes the UNARYOP wrapping and
thus, emits a warning: https://godbolt.org/z/4sh7TM4v1 [0]

Otherwise, we could also do a call to structural_equality for
unaryop_svalue inside eval_condition_without_cm and ignore a type
mismatch for unaryop_svalues.  That way, the analyzer would complain about
your example.  Not 100% sure but I think it is okay to ignore the type
here for unaryop_svalues as long as the leafs match up.  If you agree,
I can prepare a patch [1].

[0] I've seen you pushed a patch that displays the capacity as a new
    event at region_creation.  My patches did that by overwriting whats
    printed using describe_region_creation_event.  Should I remove all
    those now unneccessary describe_region_creation_event overloads?
[1] Below is how that would probably look like.

---
 gcc/analyzer/region-model.cc | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 82006405373..4a9f0ff1e86 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -4190,6 +4190,24 @@ region_model::eval_condition_without_cm (const svalue *lhs,
 	}
     }
 
+  if (lhs->get_kind () == SK_UNARYOP)
+    {
+      switch (op)
+	{
+	default:
+	  break;
+	case EQ_EXPR:
+	case LE_EXPR:
+	case GE_EXPR:
+	  {
+	    tristate res = structural_equality (lhs, rhs);
+	    if (res.is_true ())
+	      return res;
+	  }
+	  break;
+	}
+    }
+
   return tristate::TS_UNKNOWN;
 }
 
@@ -4307,9 +4325,7 @@ region_model::structural_equality (const svalue *a, const svalue *b) const
       {
 	const unaryop_svalue *un_a = as_a <const unaryop_svalue *> (a);
 	if (const unaryop_svalue *un_b = dyn_cast <const unaryop_svalue *> (b))
-	  return tristate (pending_diagnostic::same_tree_p (un_a->get_type (),
-							    un_b->get_type ())
-			   && un_a->get_op () == un_b->get_op ()
+	  return tristate (un_a->get_op () == un_b->get_op ()
 			   && structural_equality (un_a->get_arg (),
 						   un_b->get_arg ()));
       }
-- 
2.37.3


      parent reply	other threads:[~2022-09-11 12:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-10 22:19 Tim Lange
2022-09-11  8:04 ` David Malcolm
2022-09-11  8:21   ` Bernhard Reutner-Fischer
2022-09-11  8:40     ` David Malcolm
2022-09-11 12:08   ` Tim Lange [this message]

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=20220911120856.38550-1-mail@tim-lange.me \
    --to=mail@tim-lange.me \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@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).