This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] where to fix this?
- From: law at redhat dot com
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 22 Dec 2003 16:32:36 -0700
- Subject: Re: [tree-ssa] where to fix this?
- Reply-to: law at redhat dot 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