https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #25)
> in fold_unary_loc
> ---cut from fold-const.cc-----
> 9276 else if (TREE_CODE (arg0) == COND_EXPR)
> 9277 {
> 9278 tree arg01 = TREE_OPERAND (arg0, 1);
> 9279 tree arg02 = TREE_OPERAND (arg0, 2);
> 9280 if (! VOID_TYPE_P (TREE_TYPE (arg01)))
> 9281 arg01 = fold_build1_loc (loc, code, type,
> 9282 fold_convert_loc (loc,
> 9283 TREE_TYPE (op0),
> arg01));
> 9284 if (! VOID_TYPE_P (TREE_TYPE (arg02)))
> 9285 arg02 = fold_build1_loc (loc, code, type,
> 9286 fold_convert_loc (loc,
> 9287 TREE_TYPE (op0),
> arg02));
> 9288=> tem = fold_build3_loc (loc, COND_EXPR, type, TREE_OPERAND
> (arg0, 0),
> 9289 arg01, arg02);
>
> -----------end---------------
>
> gcc always tries to simplify (convert (cond (cmp a b) c d) ---- > (cond (cmp
> a b) (convert c) (convert d))， exactly the opposite of what this case wants.
It also then undos this if the result didn't simplify and plays trick to avoid
recursions.
I think this particular transform ought to be specialized, maybe to
(T)p?(T')a:(T')b or maybe done during gimplification or RTL expansion only.
The "cheap" way of avoiding a conflict is to wrap the match.pd pattern
with opposite logic in
#if GIMPLE
#endif
(with a comment explaining this)
Note that we can move a conversion out only if the sources of the conversions
have compatible types but we always can move a conversion in.
Alternatively this transform can also be done in a vectorizer pattern based
on vector compatibility of the ?: predicate with the data.
