Hi,
On Tue, 30 Oct 2012, Richard Biener wrote:
> 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.
That would be a step away from the ideal situation, so we rather should
first analyze why the testcase fails with my patch. I expected some
fallout and am actually surprised it's only one testcase :)
What we should end up with in the ideal world is that we simply have no
expressions in gimple (and hence no place to store any locations for
them), except via gimple statements.
> 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?
Since merging location and block a null BLOCK doesn't imply no location.
It can very well have a location without a block. What we might want to
imply is that a null BLOCK implies the BLOCK from the statement. But as
you say, first we should find out why my patch breaks the one testcase.
> Or rather, _why_ does Michas patch not work? Did you analyze the guality
> fails?
Ciao,
Michael.
