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
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #24 from Andrew Macleod ---
Author: amacleod
Date: Wed Jan 14 13:58:35 2015
New Revision: 219601
URL: https://gcc.gnu.org/viewcvs?rev=219601&root=gcc&view=rev
Log:
2015-01-14 Andrew MacLeod
PR middle-end/59448
* builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #23 from preshing ---
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 patch fixes it (changing the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
preshing changed:
What|Removed |Added
CC||filter-gcc at preshing dot com
--- Comment #2
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?
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 allowin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #19 from 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 if any parameter of the functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #18 from Tim Northover ---
> 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.
In case the data point is
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 forwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #16 from 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 #15 from Andrew Macleod ---
Created attachment 33831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33831&action=edit
promote memory order consume to acquire
So have we concluded that we should promote memory_order_consume to
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 fragment
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 #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 ge
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
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #9 from 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 for direct uses of the atomic buil
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::atomic flag(0);
and calculate the address this way:
d = *(&d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #7 from Andrew Pinski ---
>*(&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 #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 #5 from 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 built-ins - and yes, if this had been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #4 from algrant at acm dot org ---
So using g++,
#include
int f1(std::atomic const *p, std::atomic const *q)
{
int flag = p->load(std::memory_order_consume);
return flag ? (q + flag - flag)->load(std::memory_order_relaxe
24 matches
Mail list logo
