This is the mail archive of the
mailing list for the GCC project.
Re: RFC: PR 19650
- From: Roger Sayle <roger at eyesopen dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Thu, 27 Jan 2005 15:19:50 -0700 (MST)
- Subject: Re: RFC: PR 19650
On Thu, 27 Jan 2005, Dale Johannesen wrote:
> I'm not sure where in the twisty little passages this should be fixed,
> but fold_binary_op_with_conditional_arg is taking a type from the
> EQ_EXPR, even though that should always be boolean (right)? Which is
> suspicious, and I'm inclined to think it should be using the input type
> Does this look like the right approach?
Ahh, the perils of STRIP_NOPS. Firstly, the type that corresponds to
the result of EQ_EXPR is defined by the front-end, "bool" in C++, "int"
in C, and even several different LOGICAL(n) types in the gfortran
front-ends, so "fold" should always be using the type of the EQ_EXPR.
However, the problem is that we've lost the NOP_EXPR cast from bool
to "unsigned long" thanks to STRIP_NOPS. This stripping may also have
affected COND_EXPRs in addition to relational operations, so I think
the appropriate fix is actually something like:
if (lhs == 0)
+ true_value = fold_convert (type, true_value);
! lhs = fold (cond_first_p ? build2 (code, type, true_value, arg)
! : build2 (code, type, arg, true_value));
if (rhs == 0)
+ false_value = fold_convert (type, false_value);
! rhs = fold (cond_first_p ? build2 (code, type, false_value, arg)
! : build2 (code, type, arg, false_value));
This should avoid potential problems with true_value or false_value
being "void" in a COND_EXPR, and matches the intended semantics.
Could you see if this untested suggestion works for you?