[tree-ssa] where to fix this?

[law@redhat.com]

In message <510D269F-324E-11D8-BBD2-000A95D7CD40@apple.com>, Dale Johannesen wr
ites:
 >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?
And you're running into one of the fundamental issues -- there is no
well defined semantics to fold.  There's several messages from Roger,
Jan and myself.  The long and short is fold is (IMHO) a *&@#$ disaster
and needs a total redesign.


However, like I said before, I'd really like to see a compilable testcase
so that I can run it under the debugger and track precisely how that expression
is transformed as it moved through the compimler.

jeff