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
