From: David Malcolm <dmalcolm@redhat.com>
To: gcc@gcc.gnu.org
Subject: Valid types for a binary op in GENERIC?
Date: Wed, 14 Feb 2024 12:14:13 -0500 [thread overview]
Message-ID: <00d59a6db28ba37be5742d0718f7856fd99d0a3a.camel@redhat.com> (raw)
The ICE in PR analyzer/111441 is due to this assertion in
fold_binary_loc failing:
11722 gcc_assert (TYPE_PRECISION (atype) == TYPE_PRECISION (type));
where code=MULT_EXPR, type=<integer_type 0x7fffea6645e8 int>, and:
(gdb) p type
$1 = <integer_type 0x7fffea6645e8 int>
(gdb) p atype
$2 = <integer_type 0x7fffea6647e0 long unsigned int>
due to the analyzer building a mult_expr node with those types for the
arguments.
I have a fix for this (by adding some missing casts within the
analyzer's svalue representation), but it got me wondering: is there a
way to check valid types for binary operations in GENERIC?
Looking at
https://gcc.gnu.org/onlinedocs/gccint/Unary-and-Binary-Expressions.html
I see that for PLUS_EXPR, MINUS_EXPR and MULT_EXPR their "operands may
have either integral or floating type, but there will never be [sic]
case in which one operand is of floating type and the other is of
integral type."
Is it the case that for PLUS_EXPR, MINUS_EXPR and MULT_EXPR, their
arguments *must* have the same precision? Or that types_compatible_p
is true? What about other binary operations?
FWIW I currently have this hacked-up assertion in my working copy:
const svalue *
region_model_manager::get_or_create_binop (tree type, enum tree_code op,
const svalue *arg0,
const svalue *arg1)
{
if (arg0->get_type ()
&& arg1->get_type ()
&& op != POINTER_PLUS_EXPR)
{
// FIXME: what ops does this apply to? MULT_EXPR?
gcc_assert (types_compatible_p (arg0->get_type (), arg1->get_type ()));
}
Is there a function to check type-compatibility of the args given a
particular enum tree_code?
Sorry if I'm missing something here
Dave
next reply other threads:[~2024-02-14 17:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 17:14 David Malcolm [this message]
2024-02-14 17:38 ` Richard Biener
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=00d59a6db28ba37be5742d0718f7856fd99d0a3a.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc@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).