This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> instead.
>
> 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?

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]