http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #12 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #11)
> Author: jakub
> Date: Mon Jan 13 07:56:40 2014
> New Revision: 206572
>
> URL: http://gcc.gnu.org/viewcvs?rev=206572&root=gcc&view=rev
> Log:
> PR l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 13 07:56:40 2014
New Revision: 206572
URL: http://gcc.gnu.org/viewcvs?rev=206572&root=gcc&view=rev
Log:
PR libgomp/59194
* omp-low.c (expand_omp_atomic_pipeline): Expand t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #10 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #7)
> That said, during stage3 I'll look at how costly would be to use there
> __atomic_load_n with MEMMODEL_RELAXED.
any chance this could be looked at in the r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #8 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #7)
> And the problem with that is? Because the arithmetics is based on the value
> we've read, it shouldn't be a problem.
Ah...right.
> That said, during stag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #7 from Jakub Jelinek ---
And the problem with that is? Because the arithmetics is based on the value
we've read, it shouldn't be a problem.
That said, during stage3 I'll look at how costly would be to use there
__atomic_load_n with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #6 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #4)
> I bet tsan complains because the load is
> not atomic, but does it really matter? If we read garbage there, compare
> and swap will fail and next time we'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #5 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #4)
> I bet tsan complains because the load is
> not atomic, but does it really matter?
I think there are (at least) two possible answers to this.
1) No, it do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #4 from Jakub Jelinek ---
Because CPUs obviously don't have floating point atomic instructions, what the
compiler does is just load it as an integer, view convert to floating point,
perform arithmetics, view convert result back to inte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #3 from Joost VandeVondele
---
actually it seems more general an issue, the following:
SUBROUTINE S1(m)
REAL :: m
!$OMP ATOMIC
m=m+1.0
END
REAL :: m
m=0.0
!$OMP PARALLEL
CALL S1(m)
!$OMP END PARALLEL
END
flags race for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #1 from Andrew Pinski ---
I think this is still a dup of bug 40362.
13 matches
Mail list logo
