Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Thu, Dec 21, 2017 at 08:32:28PM -0200, Alexandre Oliva wrote: > for gcc/c-family/ChangeLog > > PR debug/83527 > PR debug/83419 > * c-semantics.c (only_debug_stmts_after_p): New. > (pop_stmt_list): Clear side effects in debug-only stmt list. > Check for single

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 21, 2017, Jakub Jelinek wrote: > On Wed, Dec 20, 2017 at 10:02:24PM -0200, Alexandre Oliva wrote: >> + if (tsi_one_before_end_p (i)) >> +TREE_SIDE_EFFECTS (t) = TREE_SIDE_EFFECTS (tsi_stmt (i)); > So DEBUG_BEGIN_STMTs after the single non-DEBUG_BEGIN_STMT

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Thu, Dec 21, 2017 at 06:29:11PM -0200, Alexandre Oliva wrote: > > PR debug/83419 > > * c-family/c-semantics.c (pop_stmt_list): Propagate side > > effects from single nondebug stmt to container list. > > Oops, this belonged in gcc/c-family/ChangeLog. I'm checking this in to > fix

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 20, 2017, Alexandre Oliva wrote: > for gcc/ChangeLog > PR debug/83419 > * c-family/c-semantics.c (pop_stmt_list): Propagate side > effects from single nondebug stmt to container list. Oops, this belonged in gcc/c-family/ChangeLog. I'm checking this

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 21, 2017, Jeff Law wrote: > FWIW I wouldn't be surprised if there's other places in reorg that are > going to need similar fixes. *nod*. I looked around, and the only place that seemed suspicious was find_end_label, but I'm not sure we might actually use a debug insn as

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 21, 2017, Jakub Jelinek wrote: > On Wed, Dec 20, 2017 at 10:02:24PM -0200, Alexandre Oliva wrote: >> --- a/gcc/c-family/c-semantics.c >> +++ b/gcc/c-family/c-semantics.c >> @@ -96,6 +96,15 @@ pop_stmt_list (tree t) >> + while (!tsi_end_p (i) >> + &&

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Wed, Dec 20, 2017 at 10:02:24PM -0200, Alexandre Oliva wrote: > --- a/gcc/c-family/c-semantics.c > +++ b/gcc/c-family/c-semantics.c > @@ -96,6 +96,15 @@ pop_stmt_list (tree t) > t = l; > tsi_link_before (, u, TSI_SAME_STMT); > } > + while (!tsi_end_p (i)

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On 12/20/2017 05:02 PM, Alexandre Oliva wrote: > On Dec 15, 2017, Richard Biener wrote: > >> On Thu, 14 Dec 2017, Jakub Jelinek wrote: >>> Hi! >>> >>> The following testcase FAILs -fcompare-debug, because one COND_EXPR >>> branch from the FE during gimplifications is just >

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On 12/20/2017 06:37 PM, Alexandre Oliva wrote: > On Dec 20, 2017, Alexandre Oliva wrote: > >> things work reasonably flawlessly now is not suggestive that it was >> easy, or not too intrusive, but rather that the work to make it seamless >> despite the intrusiveness was done,

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 20, 2017, Alexandre Oliva wrote: > things work reasonably flawlessly now is not suggestive that it was > easy, or not too intrusive, but rather that the work to make it seamless > despite the intrusiveness was done, at first, and then over time. > That's the reason for

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Dec 15, 2017, Richard Biener wrote: > On Thu, 14 Dec 2017, Jakub Jelinek wrote: >> Hi! >> >> The following testcase FAILs -fcompare-debug, because one COND_EXPR >> branch from the FE during gimplifications is just > >> which doesn't have TREE_SIDE_EFFECTS, but for

[ja...@redhat.com: Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)]

--- Begin Message --- On Mon, Dec 18, 2017 at 02:35:07PM +0100, Jakub Jelinek wrote: > On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote: > > One option would be to deal with that in pop_stmt_list and the C++ caller > > thereof, where we right now have: > > > > /* If the

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote: > One option would be to deal with that in pop_stmt_list and the C++ caller > thereof, where we right now have: > > /* If the statement list contained exactly one statement, then > extract it immediately. */ > if

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Mon, Dec 18, 2017 at 02:02:52PM +0100, Jakub Jelinek wrote: > Because make_node (STATEMENT_LIST) sets TREE_SIDE_EFFECTS, but the above > memset clears it, we start with inconsistent TREE_SIDE_EFFECTS from the > beginning. > > I've tried to track TREE_SIDE_EFFECTS precisely, as below, but that

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Fri, Dec 15, 2017 at 09:34:44AM +0100, Richard Biener wrote: > I don't like this too much. Iff then we should do "real" lazy > computation, like adding a TREE_SIDE_EFFECTS_VALID flag on STATEMENT_LIST, > keeping TREE_SIDE_EFFECTS up-to-date when easily possible and when doing > the expensive

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Fri, Dec 15, 2017 at 09:34:44AM +0100, Richard Biener wrote: > Ugh... the issue is that this difference might have many other > -fcompare-debug issues, like when folding things? Why is it a > STATEMENT_LIST rather than a COMPOUND_EXPR? I believe most of other foldings don't use

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Thu, 14 Dec 2017, Jakub Jelinek wrote: > Hi! > > The following testcase FAILs -fcompare-debug, because one COND_EXPR > branch from the FE during gimplifications is just > > which doesn't have TREE_SIDE_EFFECTS, but for -gstatement-frontiers it > is a STATEMENT_LIST which contains # DEBUG