> Yeah. But please also check gdb testsuite for this kind of patches.
This patch also passed gdb testsuite.
Thanks,
Dehao
>
> Jakub
On Wed, Oct 31, 2012 at 11:00:26AM +0100, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 6:27 PM, Dehao Chen wrote:
> >> gcc/ChangeLog:
> >> 2012-10-25 Dehao Chen
> >>
> >> * tree-eh.c (do_return_redirection): Set location for jump
> >> statement.
> >> (do_goto_redirection): L
On Tue, Oct 30, 2012 at 6:27 PM, Dehao Chen wrote:
>> gcc/ChangeLog:
>> 2012-10-25 Dehao Chen
>>
>> * tree-eh.c (do_return_redirection): Set location for jump statement.
>> (do_goto_redirection): Likewise.
>> (frob_into_branch_around): Likewise.
>> (lower_try_fin
> gcc/ChangeLog:
> 2012-10-25 Dehao Chen
>
> * tree-eh.c (do_return_redirection): Set location for jump statement.
> (do_goto_redirection): Likewise.
> (frob_into_branch_around): Likewise.
> (lower_try_finally_nofallthru): Likewise.
> (lower_try_finally_co
> The debugger isn't the only consumer of debug info, and other tools might need
> a finer granularity than a GIMPLE location, so clearing EXPR_LOCATION to work
> around a debug info size issue seems very short-sighted (to say the least).
Hi, Eric,
There might be some misunderstanding here. Clear
BTW, one thing I found confusing is that in expr.c, some code is for
frontend, while some are for rtl. Shall we separate them into two
files? And we don't expect to see EXPR_LOCATION in the rtl side.
Thanks,
Dehao
On Tue, Oct 30, 2012 at 8:29 AM, Richard Biener
wrote:
> On Tue, Oct 30, 2012 at 4:21 PM, Jakub Jelinek wrote:
>> On Tue, Oct 30, 2012 at 04:15:38PM +0100, Richard Biener wrote:
>>> So maybe TER (well, those looking up the stmt) should pick the location
>>> from the TERed statement properly then?
> I'd say either we should do the TREE_BLOCK setting on all non-shareable
> trees during gimple-low and clear the block (but then likely whole
> location?; it doesn't make sense to say in the debugger that something
> has certain source location when you can't print variables declared in that
> loc
On Tue, Oct 30, 2012 at 4:21 PM, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 04:15:38PM +0100, Richard Biener wrote:
>> So maybe TER (well, those looking up the stmt) should pick the location
>> from the TERed statement properly then?
>
> Perhaps, but Micha's patch doesn't do that.
> But in tha
On Tue, Oct 30, 2012 at 04:15:38PM +0100, Richard Biener wrote:
> So maybe TER (well, those looking up the stmt) should pick the location
> from the TERed statement properly then?
Perhaps, but Micha's patch doesn't do that.
But in that case IMHO it still would help to set all expr locations to
UNK
On Tue, Oct 30, 2012 at 4:03 PM, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 03:38:11PM +0100, Richard Biener wrote:
>> 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 ca
On Tue, Oct 30, 2012 at 03:38:11PM +0100, Richard Biener wrote:
> 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
On Tue, Oct 30, 2012 at 3:49 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 30 Oct 2012, Richard Biener wrote:
>
>> On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen wrote:
>> >> And tree expressions don't have TREE_BLOCK before gimple-low either.
>> >> So IMNSHO it is gimple-low.c that should set TREE_BLOC
Hi,
On Tue, 30 Oct 2012, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen 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
On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen 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 fronten
> 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
On Mon, Oct 29, 2012 at 05:10:10PM +0100, Richard Biener wrote:
> On Mon, Oct 29, 2012 at 4:25 PM, Dehao Chen wrote:
> > On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> >> Hi,
> >>
> >> On Mon, 29 Oct 2012, Richard Biener wrote:
> >>
> >>> > Well, you merely moved the bogus code to gimple-
Yeah, I looked into the testcase. Indeed, the expr location should be
used instead of curr_insn_location(). Otherwise the source line for
all definitions will be attributed to the use point. But if we use
EXPR_LOCATION, then we need to make sure the block is also correct.
Any suggestions how we sh
On Mon, Oct 29, 2012 at 01:40:35PM -0700, Dehao Chen wrote:
> Attached is the new patch. This patch bootstrapped and passed all
> tests except the following:
>
> FAIL: gcc.dg/guality/pr43479.c -O1 line 13 h == 9
> FAIL: gcc.dg/guality/pr43479.c -O1 line 18 h == 9
> FAIL: gcc.dg/guality/pr43479
Hi,
Attached is the new patch. This patch bootstrapped and passed all
tests except the following:
FAIL: gcc.dg/guality/pr43479.c -O1 line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -O1 line 18 h == 9
FAIL: gcc.dg/guality/pr43479.c -O2 line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -O2 line 1
Ok. I'll test Micheal's patch, and send out the new patch soon.
Thanks,
Dehao
On Mon, Oct 29, 2012 at 6:07 PM, Dehao Chen wrote:
> Hi, Micheal,
>
> Thanks for explaining the design principle of debug info with gimple,
> now I can understand your concerns. And thanks for providing the
> patch.
>
> However, in some places after gimplification (e.g. tree-inline.c), we
> still
Hi, Micheal,
Thanks for explaining the design principle of debug info with gimple,
now I can understand your concerns. And thanks for providing the
patch.
However, in some places after gimplification (e.g. tree-inline.c), we
still updates the block/location info. And EXPR_LOCATION is still used
w
On Mon, Oct 29, 2012 at 9:10 AM, Richard Biener
wrote:
> On Mon, Oct 29, 2012 at 4:25 PM, Dehao Chen wrote:
>> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Mon, 29 Oct 2012, Richard Biener wrote:
>>>
> Well, you merely moved the bogus code to gimple-low.c. It is
Hi,
On Mon, 29 Oct 2012, Dehao Chen wrote:
> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 29 Oct 2012, Richard Biener wrote:
> >
> >> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
> >> > because you unconditionally overwrite TREE_BLOCK of a
On Mon, Oct 29, 2012 at 4:25 PM, Dehao Chen wrote:
> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 29 Oct 2012, Richard Biener wrote:
>>
>>> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
>>> > because you unconditionally overwrite TREE_BLOCK of
On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 29 Oct 2012, Richard Biener wrote:
>
>> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
>> > because you unconditionally overwrite TREE_BLOCK of all operands (and all
Emm, then in gimple-low.c, we should
Hi,
On Mon, 29 Oct 2012, Richard Biener wrote:
> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
> > because you unconditionally overwrite TREE_BLOCK of all operands (and all
> > operands operands) with the statements block. I assume the unit-test you
> > added shows the pr
On Mon, Oct 29, 2012 at 2:51 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 26 Oct 2012, Dehao Chen wrote:
>
>> 1. abandon the changes in cfgexpand.c
>
> Well, you merely moved the bogus code to gimple-low.c. It is bogus
> because you unconditionally overwrite TREE_BLOCK of all operands (and all
> ope
Hi,
On Fri, 26 Oct 2012, Dehao Chen wrote:
> 1. abandon the changes in cfgexpand.c
Well, you merely moved the bogus code to gimple-low.c. It is bogus
because you unconditionally overwrite TREE_BLOCK of all operands (and all
operands operands) with the statements block. I assume the unit-test
On Sat, Oct 27, 2012 at 11:07 AM, Richard Biener
wrote:
> On Sat, Oct 27, 2012 at 12:53 AM, Dehao Chen wrote:
>> Hi,
>>
>> I've updated the patch:
>>
>> 1. abandon the changes in cfgexpand.c
>> 2. set the block for trees when lowering gimple stmt.
>> 3. add a unittest.
>
> Index: gcc/gimple-low.c
On Sat, Oct 27, 2012 at 12:53 AM, Dehao Chen wrote:
> Hi,
>
> I've updated the patch:
>
> 1. abandon the changes in cfgexpand.c
> 2. set the block for trees when lowering gimple stmt.
> 3. add a unittest.
Index: gcc/gimple-low.c
===
Hi,
I've updated the patch:
1. abandon the changes in cfgexpand.c
2. set the block for trees when lowering gimple stmt.
3. add a unittest.
However, this patch will trigger two lto bug when asserting
LTO_NO_PREVAIL for TREE_CHAIN. After debugging for a while, I found
that the problem was also the
Hi,
On Thu, 25 Oct 2012, Dehao Chen wrote:
> >> * cfgexpand.c (set_expr_location_r): New callback function.
> >> (gimple_assign_rhs_to_tree): Walk the expr recursively.
> >> (expand_call_stmt): Likewise.
> >> (expand_gimple_stmt_1): Likewise.
> >
> > This cannot be right. You're going to propaga
> I noticed that in r151350, Micheal changed from set_expr_location_r to
> SET_EXPR_LOCATION. Any insights why the recursive call is replaced?
> Looks to me if we reset the location for first level expr here, there
> is no reason that we don't reset expr for deeper levels. Or shall we
> simply remo
Binary search shows that the culprit for the recent gdb regression is
http://gcc.gnu.org/viewcvs?view=revision&revision=192719, it failed
the following tests:
gdb.base/store.exp
gdb.base/restore.exp
The block_location patch also breaks the following tests:
gdb.cp/method.exp
But the error is fix
On Thu, Oct 25, 2012 at 11:11 AM, Tom Tromey wrote:
>> "Dehao" == Dehao Chen writes:
>
> Dehao> This patch fixes debug info for expr and jump stmt.
> Dehao> Bootstrapped and passed gcc regression tests.
> Dehao> Is it okay for trunk?
>
> I wonder whether this affects the gdb test suite result
On Thu, Oct 25, 2012 at 11:06 AM, Eric Botcazou wrote:
>> This patch fixes debug info for expr and jump stmt.
>
> It would be nice to have testcases...
Sure, I'll try to forge some testcases for this.
>
>> * cfgexpand.c (set_expr_location_r): New callback function.
>> (gimple_assign_rhs_to_tree)
> "Dehao" == Dehao Chen writes:
Dehao> This patch fixes debug info for expr and jump stmt.
Dehao> Bootstrapped and passed gcc regression tests.
Dehao> Is it okay for trunk?
I wonder whether this affects the gdb test suite results.
I'm not trying to pick on you specifically, but there's been
> This patch fixes debug info for expr and jump stmt.
It would be nice to have testcases...
> * cfgexpand.c (set_expr_location_r): New callback function.
> (gimple_assign_rhs_to_tree): Walk the expr recursively.
> (expand_call_stmt): Likewise.
> (expand_gimple_stmt_1): Likewise.
This cannot be r
40 matches
Mail list logo
