On Thu, Jan 30, 2020 at 09:27:33AM -0500, David Malcolm wrote:
> --- a/gcc/analyzer/region-model.cc
> +++ b/gcc/analyzer/region-model.cc
> @@ -666,12 +666,16 @@ constant_svalue::eval_condition (constant_svalue *lhs,
> gcc_assert (CONSTANT_CLASS_P (lhs_const));
> gcc_assert (CONSTANT_CLASS_P (rhs_const));
>
> - tree comparison
> - = fold_build2 (op, boolean_type_node, lhs_const, rhs_const);
> - if (comparison == boolean_true_node)
> - return tristate (tristate::TS_TRUE);
> - if (comparison == boolean_false_node)
> - return tristate (tristate::TS_FALSE);
> + /* Check for comparable types. */
> + if (TREE_TYPE (lhs_const) == TREE_TYPE (rhs_const))
Isn't the analyzer invoked on GIMPLE? In GIMPLE, pointer equality of types
is often not guaranteed and the compiler generally doesn't care about that,
what we care about is whether the two types are compatible
(types_compatible_p). E.g. if originally both types were say long int,
but on lp64 one of the arguments was cast from long long int to long int,
you can end up with one operand long int and the other long long int;
they have the same precision etc., so it is ok to compare them.
> + {
> + tree comparison
> + = fold_build2 (op, boolean_type_node, lhs_const, rhs_const);
> + if (comparison == boolean_true_node)
> + return tristate (tristate::TS_TRUE);
> + if (comparison == boolean_false_node)
> + return tristate (tristate::TS_FALSE);
This seems to be a waste of compile time memory. fold_build2 is essentially
tem = fold_binary_loc (loc, code, type, op0, op1);
if (!tem)
tem = build2_loc (loc, code, type, op0, op1 PASS_MEM_STAT);
but as you only care if the result is boolean_true_node or
boolean_false_node, the build2_loc is unnecessary. So, just use
fold_binary instead? If it returns NULL_TREE, it won't compare equal to
either and will fall through to the TS_UNKNOWN case.
> + }
> return tristate::TS_UNKNOWN;
> }
Jakub
