[PATCH] Fix debug info for expr and jump stmt

Michael Matz matz@suse.de
Tue Oct 30 14:51:00 GMT 2012


Hi,

On Tue, 30 Oct 2012, Richard Biener wrote:

> On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen <dehao@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.



More information about the Gcc-patches mailing list