> Well, I mean by artificial here, that gimplification is done via > gimplify_expr API. As FE and ME have here different assumptions. The > ME uses internally most boolean_type_node and IMHO it should be the > variant used there. As this conversation to a single boolean_type > (with recast to result FE's boolean type on demand) has some > advantages on optimization passes. Additionally it simplifies logic > in passes on types. For example there are some expressions, which are > in general unexpected in ME as they are transformed in gimplification > (like TRUTH_ANDIF/ORIF_EXPR). By adding tree manual, you might cause > the same issue as for the logical-expression showing up now.
OK, then that's definitely not the case for Ada, so the comment is incorrect. > Well, this patch might be an alternative, but I see here potential > issues in such none-gimplified expressions for comparision and logical > not, which not necessariily have BOOLEAN_TYPE. See here the code for > fold_truth_not (and some other places) in fold-const. So I think, as > long as we have here external gimplication it is more save to check > just for integral-kind. Note that, even without "external gimplication", we still have integral types down to the tree-cfg.c check. Take ACATS c52103x at -O0. The Ada FE hands over a valid TRUTH_AND_EXPR, i.e. (BOOLEAN_TYPE, BOOLEAN_TYPE, BOOLEAN_TYPE) but the gimplifier builds a (BOOLEAN_TYPE, INTEGER_TYPE, BOOLEAN_TYPE) as it strips, then adds, then re-strips a cast to BOOLEAN_TYPE in gimplify_expr. -- Eric Botcazou
