https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #26 from Andrew Pinski ---
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #24 from Andrew Macleod amacleod at redhat dot com ---
Author: amacleod
Date: Wed Jan 14 13:58:35 2015
New Revision: 219601
URL: https://gcc.gnu.org/viewcvs?rev=219601root=gccview=rev
Log:
2015-01-14 Andrew MacLeod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #23 from preshing filter-gcc at preshing dot com ---
Hi,
I went ahead and verified this bug using a cross-compiler built from GCC 4.9.2
sources. The bug indeed exists and happens when compiling for AArch64, but not
PowerPC. Andrew's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to torvald from comment #17)
(In reply to Andrew Macleod from comment #15)
So have we concluded that we should promote memory_order_consume to
memory_order_acquire for now?
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
preshing filter-gcc at preshing dot com changed:
What|Removed |Added
CC||filter-gcc at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #20 from torvald at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #19)
* carries_dependency is about increasing optimization, not decreasing it.
If it affects when barriers are added, it does so by allowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #15 from Andrew Macleod amacleod at redhat dot com ---
Created attachment 33831
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33831action=edit
promote memory order consume to acquire
So have we concluded that we should promote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
My view is promote consume to acquire until the standards committees and
formal model people have sorted out what to do with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #17 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #15)
So have we concluded that we should promote memory_order_consume to
memory_order_acquire for now?
I also think that this is the best way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #18 from Tim Northover t.p.northover at gmail dot com ---
I am not aware of any shipping compiler that would actually try to preserve
dependencies, and nobody else mentioned any during the discussion of this
topic in ISO C++ SG1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 28 Oct 2014, torvald at gcc dot gnu.org wrote:
Alternatively, we could try to be conservative and add an acquire barrier
before the function body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #11 from algrant at acm dot org ---
Where do you get that this is racy if the access to data is not atomic? By
design, release/acquire and release/consume sequences don't require wholesale
changes to the way the data payload (in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #12 from torvald at gcc dot gnu.org ---
(In reply to algrant from comment #11)
Where do you get that this is racy if the access to data is not atomic?
In threadB(), you do:
f = flag.load(std::memory_order_consume);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #13 from algrant at acm dot org ---
I see what you mean - there is a race if threadB reads the data when the
flag is not set, i.e. in the case when the read value is never used.
Moving the read of data after the test (as in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #6 from algrant at acm dot org ---
Here is a complete C++11 test case. The code generated for the two loads
in thread B doesn't maintain the required ordering:
...
ldrbw1, [x0]
uxtbw1, w1
adrp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
*(data + f - f);
This could be undefined behavior if f is not 0 or 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #8 from algrant at acm dot org ---
I don't see how f can not be 0 or 1 here, but to make this even more clear
that there is no UB, define flag this way:
static std::atomicunsigned int flag(0);
and calculate the address this way:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Thanks for the testcase. At this point I think we need Andrew MacLeod or
Torvald Riegel to review it and assess what should happen where to fix
this (both
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 12 Dec 2013, algrant at acm dot org wrote:
demonstrates the same lack of ordering. You suggest that this might
be a problem with the atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #4 from algrant at acm dot org ---
So using g++,
#include atomic
int f1(std::atomicint const *p, std::atomicint const *q)
{
int flag = p-load(std::memory_order_consume);
return flag ? (q + flag -
24 matches
Mail list logo
