Re: Valid types for a binary op in GENERIC?

[Richard Biener <richard.guenther@gmail.com>]

> Am 14.02.2024 um 18:16 schrieb David Malcolm via Gcc <gcc@gcc.gnu.org>:
> 
> 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?

No.  The best source is the GIMPLE verifier in tree-cfg.cc

> Sorry if I'm missing something here
> Dave
>