A question about exact semantics of TRUTH_*_EXPR

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi,

May I ask what the exact semantics of TRUTH_*_EXPR is?  Specifically,
I have the following questions.

o What types can TRUTH_*_EXPR be of?

o What types can the operands of TRUTH_*_EXPR be of?

o Can the type of TRUTH_*_EXPR and that of its operands be different?

For your information, here is the comment in tree.def.

/* ANDIF and ORIF allow the second operand not to be computed if the
   value of the expression is determined from the first operand.  AND,
   OR, and XOR always compute the second operand whether its value is
   needed or not (for side effects).  The operand may have
   BOOLEAN_TYPE or INTEGER_TYPE.  In either case, the argument will be
   either zero or one.  For example, a TRUTH_NOT_EXPR will never have
   an INTEGER_TYPE VAR_DECL as its argument; instead, a NE_EXPR will be
   used to compare the VAR_DECL to zero, thereby obtaining a node with
   value zero or one.  */

The reason I am asking these questions is that while trying to fix PR
17512, I saw convert_to_integer() in convert.c contain the following.

    case INTEGER_TYPE:
    case ENUMERAL_TYPE:
    case BOOLEAN_TYPE:
    case CHAR_TYPE:
      :
      :
      else if (ex_form == TRUTH_AND_EXPR || ex_form == TRUTH_ANDIF_EXPR
	       || ex_form == TRUTH_OR_EXPR || ex_form == TRUTH_ORIF_EXPR
	       || ex_form == TRUTH_XOR_EXPR)
	{
	  expr = copy_node (expr);
	  TREE_OPERAND (expr, 0) = convert (type, TREE_OPERAND (expr, 0));
	  TREE_OPERAND (expr, 1) = convert (type, TREE_OPERAND (expr, 1));
	  TREE_TYPE (expr) = type;
	  return expr;
	}

Note that if somebody asks convert_to_integer() to convert "a ^ b" to
ENUMERAL_TYPE, then it would go ahead and do that, but then we would
end up with TRUTH_XOR_EXPR with its operands being of ENUMERAL_TYPE,
which is inconsistent with the comment in tree.def.

Andrew Pinski claims that the above "else if" clause is bogus and
should be removed, and I mostly agree with him, but the code has been
around for too long....

Thanks in advance,

Kazu Hirata