On 06/06/2015 05:34 AM, Marc Glisse wrote:
Hello,

as discussed around
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00041.html
we are currently guessing the type of a?b:c incorrectly. This does not
affect current simplifications, because the only 'cond' in output
patterns are at the outermost level, so their type is forced to 'type'
and never guessed. Indeed, the patch does not change the generated
*-match.c. It would allow removing an explicit cond:itype in a patch
posted by Jeff.

I tested it on a dummy .pd file containing:
(simplify
  (plus @0 (plus @1 @2))
  (negate (cond @0 @1 @2)))

and the generated files differ by:

-  res = fold_build3_loc (loc, COND_EXPR, TREE_TYPE (ops1[0]), ops1[0],
ops1[1], ops1[2]);
+  res = fold_build3_loc (loc, COND_EXPR, TREE_TYPE (ops1[1]), ops1[0],
ops1[1], ops1[2]);

(and something similar for gimple)

I wondered about using something like
VOID_TYPE_P (TREE_TYPE (ops1[1])) ? TREE_TYPE (ops1[2]) : TREE_TYPE
(ops1[1])
but I don't think that will be necessary.

Bootstrap is currently broken on many platforms with comparison
failures, but since it went that far and generated the same *-match.c
files, that seems sufficient testing.

2015-06-08  Marc Glisse  <marc.gli...@inria.fr>

     * genmatch.c (expr::gen_transform): For conditions, guess the type
     from the second operand.
Thanks for taking care of this. I'd gone back and verified the type was needed, but didn't have to time reduce a testcase for it prior to going on PTO.

Jeff

Reply via email to