On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen <de...@google.com> wrote:
>> And tree expressions don't have TREE_BLOCK before gimple-low either.
>> So IMNSHO it is gimple-low.c that should set TREE_BLOCK of all the gimple
>> stmts as well as all expression in the operands. It is not overwriting
>> anything, no frontend sets TREE_BLOCK for any expression, the way frontends
>> associate IL with BLOCKs is by putting them inside of BIND_EXPR/GIMPLE_BIND
>> after gimplification, and it is gimple-low responsibility to set it.
>>
>> In 4.3 before tuples, it was solely gimple-low that set TREE_BLOCK
>> initially. Before the location_t changes, again it was gimple-low that
>> was the first setter of TREE_BLOCK, which was valid for all
>> IS_EXPR_CODE_CLASS. So, IMNSHO gimple-low should merge location_t
>> with block for all gimple stmts and all tree expressions used in its
>> operands. It shouldn't be set on trees that can be shared, so
>> say decls etc. should keep using just location_t's without associated block.
>> So perhaps the right test for gimple-low setting of block is
>> CAN_HAVE_LOCATION_P (exp) && !tree_node_can_be_shared (exp).
>>
>> Jakub
>
> I Kind of like this idea. What do you guys think?
I question the need of BLOCK info on expression trees. If BLOCKs are
relevant then the tree ends up referencing a declaration with a BLOCK as
context, no? Thus, the case
int tem, a;
{
int a;
...
tem = a;
}
int b = tem + 5;
where we may end up with gimple like
b = a + 5;
thus mixing two BLOCKs inside a stmt (and no expression trees to
attach different BLOCKs) is no different from the case where we end
up with expression trees.
Thus my original question - why isn't a NULL BLOCK treated the same
as UNKNOWN_LOCATION? Or rather, _why_ does Michas patch not work?
Did you analyze the guality fails?
Thanks,
Richard.
> Thanks,
> Dehao
