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.children != NULL)
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
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 with
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 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
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 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.
Actually,
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?
I
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 Development
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 powerpc-linux.
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.c
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
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_lock
13 matches
Mail list logo
