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
prev 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).