On Wed, 2013-01-23 at 11:41 +1030, Alan Modra wrote:
> On Tue, Jan 22, 2013 at 02:20:23PM +0100, Torvald Riegel wrote:
> > > @@ -116,11 +116,10 @@ GOMP_task (void (*fn) (void *), void *data, void (
> > > }
> > >else
> > > fn (data);
> > > - if (team != NULL)
> > > + if (task.c
On Tue, Jan 22, 2013 at 02:20:23PM +0100, Torvald Riegel wrote:
> > @@ -116,11 +116,10 @@ GOMP_task (void (*fn) (void *), void *data, void (
> > }
> >else
> > fn (data);
> > - if (team != NULL)
> > + if (task.children != NULL)
>
> Why does this not need an acquire barrier
On Tue, Jan 22, 2013 at 01:01:24PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 22, 2013 at 10:22:00PM +1030, Alan Modra wrote:
> > On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> > > Looks good to me.
> >
> > Thanks for the amazingly quick review! Committed revision 195370.
>
> Ac
On Tue, 2013-01-22 at 21:33 +1030, Alan Modra wrote:
> SPEComp2012 376.kdtree shows a huge regression after my PR51376 fix,
> with the benchmark, which finishes normally in a few minutes, failing
> to complete after hours of running on a power7 machine. Using a
> reduced data set showed typically
On Tue, Jan 22, 2013 at 10:22:00PM +1030, Alan Modra wrote:
> On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> > Looks good to me.
>
> Thanks for the amazingly quick review! Committed revision 195370.
Actually, there is one thing I'm worried about, -lgomp doesn't link against
-la
On Tue, Jan 22, 2013 at 12:19:21PM +0100, Jakub Jelinek wrote:
> Looks good to me.
Thanks for the amazingly quick review! Committed revision 195370.
Is the patch OK for 4.7 too?
--
Alan Modra
Australia Development Lab, IBM
On Tue, Jan 22, 2013 at 09:33:25PM +1030, Alan Modra wrote:
> Bootstrapped and regression tested powerpc64-linux. OK to apply?
>
> PR libgomp/51376
> PR libgomp/56073
> * task.c (GOMP_task): Revert 2011-12-09 change.
> (GOMP_taskwait): Likewise. Instead use atomic load wi
SPEComp2012 376.kdtree shows a huge regression after my PR51376 fix,
with the benchmark, which finishes normally in a few minutes, failing
to complete after hours of running on a power7 machine. Using a
reduced data set showed typically over a 200x slowdown. So, why is
this happening? Well, it a
On Fri, Dec 02, 2011 at 08:10:11PM +1030, Alan Modra wrote:
> PR libgomp/51376
> * task.c (GOMP_taskwait): Don't access task->children outside of
> task_lock mutex region.
> (GOMP_task): Likewise.
Committed revision 182151 on rth's irc OK.
--
Alan Modra
Australia Developm
On Fri, Dec 02, 2011 at 08:10:11PM +1030, Alan Modra wrote:
> On Thu, Dec 01, 2011 at 12:36:08PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> > > The GOMP_task change fixes a similar potential problem. Bootstrapped
> > > and regression tested powerp
On Thu, Dec 01, 2011 at 12:36:08PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> > The GOMP_task change fixes a similar potential problem. Bootstrapped
> > and regression tested powerpc-linux. OK to apply?
> >
> > PR libgomp/51376
> > * task.
On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> The GOMP_task change fixes a similar potential problem. Bootstrapped
> and regression tested powerpc-linux. OK to apply?
>
> PR libgomp/51376
> * task.c (GOMP_taskwait): Don't access task->children outside of
> task_
The simple one-line fix in GOMP_taskwait took many hours to find.
Shared memory problems are a pain to debug, especially when adding
code to dump some state turns a testcase that fails every hundred or
so runs into one that takes thousands of times longer to fail.
What happens here is that GOMP_ta
13 matches
Mail list logo
