On Fri, Jun 03, 2016 at 09:29:48AM -0600, Martin Sebor wrote:
> >>+ {
> >>+ tree type = TREE_TYPE (TREE_TYPE (t));
> >>+ tree vflow = arith_overflowed_p (opcode, type, arg0, arg1)
> >>+ ? integer_one_node : integer_zero_node;
> >
> >This looks incorrect, the return type is TREE_TYPE (t), some complex integer
> >type, therefore vflow needs to be
> > tree vflow = build_int_cst (TREE_TYPE (TREE_TYPE (t)),
> > arith_overflowed_p (opcode, type, arg0, arg1)
> > ? 1 : 0);
> >no?
>
> I guess it didn't think it mattered since the complex type specifies
> the types of the two members. I don't mind changing it if it does
Sure, it does. But if there are any differences between the lhs and rhs
type (or e.g. in COMPLEX_EXPR args etc. in GENERIC), then it is invalid IL,
or for GIMPLE if the two types aren't compatible according to the GIMPLE
rules (useless conversion).
Jakub
