On Fri, Feb 27, 2015 at 02:31:38PM +0100, Andreas Schwab wrote:
> Sebastian Pop writes:
>
> > +void
> > +baz (void)
> > +{
> > + while (1)
> > +{
> > + a = foo ();
> > + b = foo ();
>
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-9.c (test for excess errors)
> Excess errors:
> /daten/ara
Sebastian Pop writes:
> +void
> +baz (void)
> +{
> + while (1)
> +{
> + a = foo ();
> + b = foo ();
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-9.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20150227/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-9.c:45:11:
error: too f
Jeff Law wrote:
> On 02/25/15 12:18, Sebastian Pop wrote:
> >Jeff Law wrote:
> >>On 02/18/15 15:27, Sebastian Pop wrote:
> The dumps for the FSM threads are a bit sparse -- they don't show
> the entire path. That makes it much harder to see what's going on.
> >>>
> >>>Would a patch improvi
On Thu, Feb 26, 2015 at 7:56 AM, Jeff Law wrote:
> On 02/13/15 16:50, Sebastian Pop wrote:
>>
>> Hi,
>>
>> the attached patch fixes PR65048 by checking before jump-threading that a
>> path
>> to be threaded is still valid: as the testcase shows, there may be paths
>> that
>> are not connected anym
On 02/13/15 16:50, Sebastian Pop wrote:
Hi,
the attached patch fixes PR65048 by checking before jump-threading that a path
to be threaded is still valid: as the testcase shows, there may be paths that
are not connected anymore because the cfg has changed in a previous jump-thread.
PR t
On 02/13/15 16:50, Sebastian Pop wrote:
Hi,
the attached patch fixes PR65048 by checking before jump-threading that a path
to be threaded is still valid: as the testcase shows, there may be paths that
are not connected anymore because the cfg has changed in a previous jump-thread.
PR t
On 02/25/15 11:37, Sebastian Pop wrote:
Jeff Law wrote:
Registering FSM jump thread: (10, 12) (12, 13) (13, 15) (15, 3)
[ snip ]
Registering FSM jump thread: (7, 10) (10, 12) (12, 13) (13, 14)
What I'm having a bit of trouble wrapping my head around is how can
those two paths b
On 02/25/15 12:18, Sebastian Pop wrote:
Jeff Law wrote:
On 02/18/15 15:27, Sebastian Pop wrote:
The dumps for the FSM threads are a bit sparse -- they don't show
the entire path. That makes it much harder to see what's going on.
Would a patch improving the FSM dumps ok to commit separately t
Jeff Law wrote:
> On 02/18/15 15:27, Sebastian Pop wrote:
> >>The dumps for the FSM threads are a bit sparse -- they don't show
> >>the entire path. That makes it much harder to see what's going on.
> >
> >Would a patch improving the FSM dumps ok to commit separately to trunk?
> Most definitely.
Jeff Law wrote:
> >Registering FSM jump thread: (10, 12) (12, 13) (13, 15) (15, 3)
> [ snip ]
> >Registering FSM jump thread: (7, 10) (10, 12) (12, 13) (13, 14)
>
> What I'm having a bit of trouble wrapping my head around is how can
> those two paths both be valid when you register t
On 02/18/15 15:27, Sebastian Pop wrote:
Jeff Law wrote:
These kinds of situations are normally pruned out in mark_threaded_blocks.
I added the FSM code generation before calling mark_threaded_blocks.
OK. Hmm. Makes me wonder what happens if we have a normal jump thread
path embedded inside
Jeff Law wrote:
> These kinds of situations are normally pruned out in mark_threaded_blocks.
I added the FSM code generation before calling mark_threaded_blocks.
>
> The dumps for the FSM threads are a bit sparse -- they don't show
> the entire path. That makes it much harder to see what's goin
On 02/13/15 16:50, Sebastian Pop wrote:
Hi,
the attached patch fixes PR65048 by checking before jump-threading that a path
to be threaded is still valid: as the testcase shows, there may be paths that
are not connected anymore because the cfg has changed in a previous jump-thread.
PR t
Hi,
the attached patch fixes PR65048 by checking before jump-threading that a path
to be threaded is still valid: as the testcase shows, there may be paths that
are not connected anymore because the cfg has changed in a previous jump-thread.
PR tree-optimization/65048
* tree-ssa-t
14 matches
Mail list logo
