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 nond
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 stmt in
> the STATEM
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 it
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 in to
fix it.
diff
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
the insertion poi
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)
>> + && TREE_CODE (tsi_stmt (i)
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 (&i, u, TSI_SAME_STMT);
> }
> + while (!tsi_end_p (i)
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 >
>>> which doesn't have
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, at first, and then o
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 -fcompare-debug and
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 -gstatement-frontiers it
>>
--- 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 stateme
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
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 s
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 th
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 TREE_SIDE_EFFE
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 BEGIN
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 BEGIN_STMT and that >. Neither # DEBUG BEGIN_STMT nor that
18 matches
Mail list logo
