http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Uros Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #14 from uros at gcc dot gnu.org 2013-01-27 14:28:23 UTC ---
Author: uros
Date: Sun Jan 27 14:28:19 2013
New Revision: 195495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195495
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #13 from uros at gcc dot gnu.org 2013-01-22 20:58:45 UTC ---
Author: uros
Date: Tue Jan 22 20:58:37 2013
New Revision: 195386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195386
Log:
PR target/56028
* confi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Uros Bizjak changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #11 from Uros Bizjak 2013-01-22 08:46:48
UTC ---
I was thinking of removing (!o,n) alternative from movdi (together with
corresponding splitters). Splitter/peephole2 actually always generates movabs
$N,%reg; mov $reg,(mem) unle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|http:/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #8 from Paul E. McKenney
2013-01-19 12:35:12 UTC ---
Indeed, different hardware implementations can cause all sorts of mischief.
Nevertheless, the compiler should not also provide mischief in these cases.
In addition, as not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Pawel Sikora changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #6 from Paul E. McKenney
2013-01-18 17:40:13 UTC ---
The fact that a data-race-free program cannot observe the non-atomicity of a
64-bit store, though true, is beside the point. The plain fact is that
hardware registers (for w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #5 from Evgeniy Stepanov
2013-01-18 16:38:11 UTC ---
Well, it's true that classes have assignment operators, and basic types don't.
But this does not have anything to do with how the assignment could (or could
not) be implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #4 from Paul E. McKenney
2013-01-18 16:22:49 UTC ---
(In reply to comment #3)
> So, what are these "rules of the abstract machine", and why do they allow
> non-atomic store of a large volatile aggregate (it is definitely not at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #3 from Evgeniy Stepanov
2013-01-18 11:57:07 UTC ---
(In reply to comment #2)
> See 1.9p8 of the C++11 standard, first bullet:
>
> "Access to volatile objects are evaluated strictly according to the rules of
> the abstract m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #2 from Paul E. McKenney
2013-01-18 11:25:52 UTC ---
(In reply to comment #1)
> - Does language standard guarantee atomic store in this case [wikipedia says
> "No." [1]]?
The above example of device drivers storing constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #1 from Uros Bizjak 2013-01-18 11:09:42
UTC ---
- Does language standard guarantee atomic store in this case [wikipedia says
"No." [1]]?
- Can a store to a volatile DImode location be implemented as two consecutive
SImode st
15 matches
Mail list logo
