> Btw, isn't this the issue? You'd need to avoid this as well I guess:
>
> /* Special case comparing booleans against a constant as we
> know the value of OP0 on both arms of the branch. i.e., we
> can record an equivalence for OP0 rather than COND.
>
> However, don't do this if the constant isn't zero or one.
> Such conditionals will get optimized more thoroughly during
> the domwalk. */
> if ((code == EQ_EXPR || code == NE_EXPR)
> && TREE_CODE (op0) == SSA_NAME
> && ssa_name_has_boolean_range (op0)
> && is_gimple_min_invariant (op1)
> && (integer_zerop (op1) || integer_onep (op1)))
> {
> ...
>
> and thus:
>
> bool
> ssa_name_has_boolean_range (tree op)
> {
> gcc_assert (TREE_CODE (op) == SSA_NAME);
>
> /* Boolean types always have a range [0..1]. */
> if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE)
> return true;
>
> as said, there are _very_ many places in the compiler you'd need to "fix".
I don't think so, you just need to prevent the compiler from creating boolean
values that are not zero and one, there is none in a valid Ada program. This
has worked perfectly for years, it's because factor_out_conditional_conversion
breaks the documented interface of int_fits_type_p by sending it a boolean
type instead of an integer type that the regression was introduced. This was
unfortunatelty not caught in the review, so we need to do damage control now,
including on the 6 branch, and my patch is a rather safe way of doing it.
> Basically treating BOOLEAN_TYPE this way is to cover frontends like
> fortran who have multiple boolean types of different size (and not precision
> 1 IIRC). An alternative would be to track them all down and force their
> precision to 1 with unknown fallout. And then document BOOLEAN_TYPE
> isn't really special anymore (and fix all places). But then, why do we have
> BOOLEAN_TYPE ...
I think BOOLEAN_TYPE essentially works fine for Ada if you don't try to treat
it like an INTEGER_TYPE, as the new factor_out_conditional_conversion does...
--
Eric Botcazou
