This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: PR 19650
- From: Dale Johannesen <dalej at apple dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Dale Johannesen <dalej at apple dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Fri, 28 Jan 2005 12:44:52 -0800
- Subject: Re: RFC: PR 19650
- References: <Pine.LNX.4.44.0501271504001.26507-100000@www.eyesopen.com>
On Jan 27, 2005, at 2:19 PM, Roger Sayle wrote:
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));
+ }
Could you see if this untested suggestion works for you?
Unfortunately, this breaks bootstrap on ppc due to miscompiling some of
the PPC-specific
code, which boils down to this loop:
unsigned int i;
for (i = 0;
((i) < 4 ? (i) + 3 : (~(unsigned int) 0)) != (~(unsigned
int) 0);
++i)
continue;
Yes, that is a stupid way to write i=4, but there it is (well hidden by
macros of course).
fold is presented with the following:
<ne_expr 0x4267e4e0
type <integer_type 0x4260b680 int public SI
arg 0 <cond_expr 0x4267e4b0
type <integer_type 0x4260b700 unsigned int public unsigned SI
arg 0 <le_expr 0x4267e450 type <integer_type 0x4260b680 int>
arg 0 <var_decl 0x42680880 i>
arg 1 <integer_cst 0x42684000 constant invariant 3>>
arg 1 <plus_expr 0x4267e480 type <integer_type 0x4260b700
unsigned int>
arg 0 <var_decl 0x42680880 i>
arg 1 <integer_cst 0x42684000 3>>
arg 2 <integer_cst 0x42606640 constant invariant 4294967295>>
arg 1 <integer_cst 0x42606640 4294967295>>
and the transformation above changes 4294967295 to -1, which compares
as != 429467295.
Now what? Perhaps the transformation should not be applied in the
COND_EXPR case?