Re: [tree-ssa] where to fix this?

[Dale Johannesen <dalej at apple dot com>]

On Dec 19, 2003, at 8:17 AM, law@redhat.com wrote:
> In message <978715DA-31C9-11D8-B11A-000A95D7CD40@apple.com>, Dale 
> Johannesen wr
> ites:
> > I have a case where tree-ssa is calling fold() on this:
> >
> > <plus_expr 0x9c80a0
> >     type <integer_type 0x40d42528 int SI
> >         size <integer_cst 0x8e4780 constant invariant 32>
> >         unit size <integer_cst 0x8e4798 constant invariant 4>...
> >     invariant
> >     arg 0 <integer_cst 0x40d40570 type <boolean_type 0x40d427f8 _Bool>
> > constant invariant 1>
> >     arg 1 <integer_cst 0x97eed0 type <integer_type 0x40d42528 int>
> > constant invariant 1>>
> >
> > which gets into int_const_binop, which thinks the result is _Bool and
> > truncates it to 0.
> > Not what we want.  Would the preference be to fix this in fold(), or
> > make tree_ssa
> > produce trees that incorporate the C promotions?
> We'd need more context to know what's happening.   testcases help a 
> lot :-)

I'm not asking anybody to fix the bug, I will do that, I just want to 
know what the
defined semantics of fold() are.  Is is supposed to handle the tree 
above or not?

This arises from perlbmk in SPEC compiled -O3.  It hangs at runtime and 
I'm surprised
nobody else has seen it.  The original code was

  x = (p !=0) + (q!=0)

and after a few rounds of optimization it transforms into the above.
I haven't tried to construct a small test yet, but it should certainly 
be possible.