COND_EXPR (?:) and its first operand in gimple

COND_EXPR (?:) and its first operand in gimple

[Andrew Pinski (QUIC)]

While looking into PR 114666, I noticed that we don't verify COND_EXPR's first operand. In most of my recent patches to match.pd, I was assuming that it would be a boolean (or a type which would contain
[0,1]) but this PR shows we could end up with an 1-bit signed integer in there.
We could fix most of the match patterns which assume we would get a boolean like type or we could fix the patterns which would create this.
Both are not hard to do but it would be useful for GCC 15 at least to add a verifier if we decide the type should not be a signed 1bit integer.

Thoughts?

Thanks,
Andrew

PS sorry about the duplicated emails, I had a typo in the email address.

Re: COND_EXPR (?:) and its first operand in gimple

[Richard Biener]

On Tue, Apr 9, 2024 at 11:02 PM Andrew Pinski (QUIC)
<quic_apinski@quicinc.com> wrote:
>
> While looking into PR 114666, I noticed that we don't verify COND_EXPR's first operand. In most of my recent patches to match.pd, I was assuming that it would be a boolean (or a type which would contain
> [0,1]) but this PR shows we could end up with an 1-bit signed integer in there.

Yeah, I guess we never had verification for is_gimple_val operands in
there.  I think we want
a boolean there, anything that's valid as a scalar result of a
tcc_comparison.  Note that
there we do allow a signed 1-bit result ...

> We could fix most of the match patterns which assume we would get a boolean like type or we could fix the patterns which would create this.
> Both are not hard to do but it would be useful for GCC 15 at least to add a verifier if we decide the type should not be a signed 1bit integer.
>
> Thoughts?
>
> Thanks,
> Andrew
>
> PS sorry about the duplicated emails, I had a typo in the email address.