https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
mwahab at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||4.9.4
--- Comment #74 from mw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #73 from Ramana Radhakrishnan ---
Now fixed ,Matthew ?
Ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #72 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 13:43:04 2015
New Revision: 226628
URL: https://gcc.gnu.org/viewcvs?rev=226628&root=gcc&view=rev
Log:
Backport from trunk:
2015-06-29 Matthew Waha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #71 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 13:40:14 2015
New Revision: 226627
URL: https://gcc.gnu.org/viewcvs?rev=226627&root=gcc&view=rev
Log:
Backport from trunk:
2015-06-29 Matthew Waha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #70 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 13:27:41 2015
New Revision: 226625
URL: https://gcc.gnu.org/viewcvs?rev=226625&root=gcc&view=rev
Log:
Backport from trunk:
2015-06-29 Matthew Waha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #69 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 11:48:43 2015
New Revision: 226621
URL: https://gcc.gnu.org/viewcvs?rev=226621&root=gcc&view=rev
Log:
Backport from trunk
2015-06-01 Matthew Wahab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #68 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 11:40:25 2015
New Revision: 226620
URL: https://gcc.gnu.org/viewcvs?rev=226620&root=gcc&view=rev
Log:
Backport from trunk.
2015-06-01 Matthew Waha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #67 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 11:29:28 2015
New Revision: 226619
URL: https://gcc.gnu.org/viewcvs?rev=226619&root=gcc&view=rev
Log:
Backport from trunk.
2015-06-01 Matthew Waha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #66 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 11:20:59 2015
New Revision: 226618
URL: https://gcc.gnu.org/viewcvs?rev=226618&root=gcc&view=rev
Log:
Backport from trunk
2015-05-12 Andrew MacLeo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #65 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:12:12 2015
New Revision: 225134
URL: https://gcc.gnu.org/viewcvs?rev=225134&root=gcc&view=rev
Log:
2015-06-29 Matthew Wahab
PR target/65697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #64 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:09:10 2015
New Revision: 225133
URL: https://gcc.gnu.org/viewcvs?rev=225133&root=gcc&view=rev
Log:
2015-06-29 Matthew Wahab
PR target/65697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #63 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:03:34 2015
New Revision: 225132
URL: https://gcc.gnu.org/viewcvs?rev=225132&root=gcc&view=rev
Log:
2015-06-29 Matthew Wahab
PR target/65697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #62 from mwahab at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #61)
> Well, confirmed at least. And at the minute fixed on trunk - not sure if we
> are asking for backports for this ?
Marcus has asked for this t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #60 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 1 15:24:37 2015
New Revision: 223986
URL: https://gcc.gnu.org/viewcvs?rev=223986&root=gcc&view=rev
Log:
PR target/65697
* gcc.target/aarch64/sync-com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #59 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 1 15:21:02 2015
New Revision: 223984
URL: https://gcc.gnu.org/viewcvs?rev=223984&root=gcc&view=rev
Log:
PR target/65697
* config/aarch64/aarch64.c (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #58 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 1 15:18:19 2015
New Revision: 223983
URL: https://gcc.gnu.org/viewcvs?rev=223983&root=gcc&view=rev
Log:
PR target/65697
* config/aarch64/aarch64.c (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #57 from Andrew Macleod ---
Author: amacleod
Date: Tue May 12 20:01:47 2015
New Revision: 223096
URL: https://gcc.gnu.org/viewcvs?rev=223096&root=gcc&view=rev
Log:
2015-05-12 Andrew MacLeod
PR target/65697
* coret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #56 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #55)
> (In reply to torvald from comment #49)
>
> > This is the case of allowing non-DRF normal accesses. The *other* case I
> > was thinking about is h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #55 from James Greenhalgh ---
(In reply to torvald from comment #49)
> > bar = 0, foo = 0;
> >
> > thread_a {
> > __sync_lock_test_and_set (foo, 1)
> > bar = 1
> > }
> >
> > thread_b {
> > /* If we can see the write to bar, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #54 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #53)
> (In reply to Andrew Macleod from comment #50)
> > Created attachment 35478 [details]
> > implement SYNC flag for memory model
> >
> > This compiles on all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #53 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #50)
> Created attachment 35478 [details]
> implement SYNC flag for memory model
>
> This compiles on all targets, but is only runtime tested on
> x86_64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #52 from Andrew Macleod ---
(In reply to mwahab from comment #51)
> The mips backend was the only one that stood out as needing some care,
> because the way it uses the memory models (e.g. in function
> mips_process_sync_loop) is a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #51 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #50)
> Created attachment 35478 [details]
> implement SYNC flag for memory model
>
> > Adding the __sync barriers to coretypes.h is the better approach if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Andrew Macleod changed:
What|Removed |Added
Attachment #35425|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #49 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #43)
> (In reply to torvald from comment #37)
> > (In reply to James Greenhalgh from comment #35)
> > > So by the strict letter of the specification, no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #48 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #47)
> Created attachment 35425 [details]
> potential patch to add MEMMODEL_SYNC
>
> I don't know where we've finally settled on this, but I did prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #47 from Andrew Macleod ---
Created attachment 35425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35425&action=edit
potential patch to add MEMMODEL_SYNC
I don't know where we've finally settled on this, but I did prototype ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #46 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #45)
> (In reply to mwahab from comment #44)
>
> And this final sentence is buggy by omission of a mention of memory writes:
>
> but following memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #45 from James Greenhalgh ---
(In reply to mwahab from comment #44)
> (In reply to James Greenhalgh from comment #43)
> > (In reply to torvald from comment #37)
> >
> > > > I'm not worried about __sync_lock_release, I think the docum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #44 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #43)
> (In reply to torvald from comment #37)
>
> > > I'm not worried about __sync_lock_release, I think the documentation is
> > > strong enough and un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #43 from James Greenhalgh ---
(In reply to torvald from comment #37)
> (In reply to James Greenhalgh from comment #35)
> > (In reply to torvald from comment #32)
> > > (In reply to James Greenhalgh from comment #28)
> > > > This also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #42 from Richard Henderson ---
(In reply to Andrew Macleod from comment #39)
> no, __sync was simply an implementation of psABI back when it was new... I'm
> not aware of any additions, enhancements or guarantees that were added when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #41 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #38)
> (In reply to Andrew Macleod from comment #34)
>
> Also, if you look at the IA-64 __sync_lock_release vs. GCC docs'
> __sync_lock_release, the latter is li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #40 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #25)
> Documentation needs updating for sure... The rules have changed under us
> since originally SEQ_CST and sync were intended to be the same thing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #39 from Andrew Macleod ---
(In reply to torvald from comment #38)
> (In reply to Andrew Macleod from comment #34)
> > > However, I guess some people relying on data races in their programs could
> > > (mis?)understand the __sync_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #38 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #34)
> > However, I guess some people relying on data races in their programs could
> > (mis?)understand the __sync_lock_release semantics to mean that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #37 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #35)
> (In reply to torvald from comment #32)
> > (In reply to James Greenhalgh from comment #28)
> > > This also gives us an easier route to fixing any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #36 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #31)
>
>
> Targets that don't need special sync patterns (ie most of them) simply don't
> provide them. The expanders see no sync pattern and use SEQ_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #35 from James Greenhalgh ---
(In reply to torvald from comment #32)
> (In reply to James Greenhalgh from comment #28)
> > This also gives us an easier route to fixing any issues with the
> > acquire/release __sync primitives (__sync_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #34 from Andrew Macleod ---
> However, I guess some people relying on data races in their programs could
> (mis?)understand the __sync_lock_release semantics to mean that it is a
> means to get the equivalent of a C11 release *fence*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #33 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #32)
> (In reply to James Greenhalgh from comment #28)
> > (In reply to torvald from comment #24)
> > > 3) We could do something just on ARM (and scan other arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #32 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #28)
> (In reply to torvald from comment #24)
> > 3) We could do something just on ARM (and scan other arcs for similar
> > issues). That's perhaps the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #31 from Andrew Macleod ---
(In reply to mwahab from comment #30)
> (In reply to James Greenhalgh from comment #28)
>
> > I don't think this is particularly onerous for a target. The tough part in
> > all of this is figuring out the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #30 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #28)
> Which leaves 3). From Andrew's two proposed solutions:
>
> > a) introduce an additional memory model... MEMMODEL_SYNC or something
> > which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #29 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #27)
> (In reply to Andrew Macleod from comment #25)
> > My opinion:
> >
> > 1) is undesirable... even though it could possibly accelerate the conversion
> > of l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #28 from James Greenhalgh ---
(In reply to torvald from comment #24)
> I think we need to at least clarify the documentation of __atomic, probably
> also of __sync; we might also have to change the implementation of __sync
> builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #27 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #25)
> My opinion:
>
> 1) is undesirable... even though it could possibly accelerate the conversion
> of legacy sync to atomic calls... I fear it would in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #26 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #21)
> (In reply to Andrew Haley from comment #20)
> > (In reply to mwahab from comment #19)
> > > (In reply to Andrew Haley from comment #18)
> > >
> > > It loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #25 from Andrew Macleod ---
My opinion:
1) is undesirable... even though it could possibly accelerate the conversion of
legacy sync to atomic calls... I fear it would instead just cause frustration,
annoyance and worse. I don't thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #24 from torvald at gcc dot gnu.org ---
I think we need to at least clarify the documentation of __atomic, probably
also of __sync; we might also have to change the implementation of __sync
builtins on some archs.
First, I think the _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #23 from James Greenhalgh ---
(In reply to torvald from comment #22)
> (In reply to James Greenhalgh from comment #12)
> > There are two problems here, one of which concerns me more in the real
> > world, and both of which rely on rac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #22 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #12)
> There are two problems here, one of which concerns me more in the real
> world, and both of which rely on races if you are in the C/C++11 model -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to Andrew Haley from comment #20)
> (In reply to mwahab from comment #19)
> > (In reply to Andrew Haley from comment #18)
> >
> > It looks inconsistent with C11 S7.17.7.4-2 (C++11 S29.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #20 from Andrew Haley ---
(In reply to mwahab from comment #19)
> (In reply to Andrew Haley from comment #18)
>
> It looks inconsistent with C11 S7.17.7.4-2 (C++11 S29.6.4-21) "Further, if
> the comparison is true, memory is affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #19 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Haley from comment #18)
> (In reply to mwahab from comment #17)
>
> >
> > int cas(int* barf, int* expected, int* desired)
> > {
> > return __atomic_compare_exchange_n(b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #18 from Andrew Haley ---
(In reply to mwahab from comment #17)
>
> int cas(int* barf, int* expected, int* desired)
> {
> return __atomic_compare_exchange_n(barf, expected, desired, 0,
>__AT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #17 from mwahab at gcc dot gnu.org ---
According to the GCC documentation, __atomic_compare_exchange(ptr, exp, des,
..) is: if (*ptr == *exp) *ptr = *exp; else *exp = *ptr;
On Aarch64 the else (*ptr != *exp) branch is a store rather t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #16 from Andrew Haley ---
(In reply to mwahab from comment #14)
> (In reply to Andrew Haley from comment #13)
> > But LDAXR/STLXR doesn't do that, and there's no write barrier at all when
> > the compare fails. If the intention real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #15 from Jakub Jelinek ---
(In reply to mwahab from comment #14)
> The LDAXR/STLXR sequences rely on the C11/C++11 prohibition of data races.
> That the __atomic builtins assume this restriction is implied by the
> references to C11/C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #14 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Haley from comment #13)
> There's surely a documentation problem here.
>
> GCC defines this:
>
> `__ATOMIC_SEQ_CST'
> Full barrier in both directions and synchronizes wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Andrew Haley changed:
What|Removed |Added
CC||aph at gcc dot gnu.org
--- Comment #13 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #11 from Matthew Wahab ---
(In reply to Andrew Macleod from comment #10)
> (In reply to Matthew Wahab from comment #7)
>
> > Ok, my point was just that an __sync operation has a stronger barrier that
> > an __atomic operation.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #10 from Andrew Macleod ---
(In reply to Matthew Wahab from comment #7)
> (In reply to torvald from comment #5)
> > (In reply to Matthew Wahab from comment #0)
> >
> > I don't think that's a precise characterization. The difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #9 from Matthew Wahab ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Matthew Wahab from comment #7)
> > I agree that this wouldn't affect valid C11 code (because of data-races) but
> > my understanding is that __sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #8 from Jonathan Wakely ---
(In reply to Matthew Wahab from comment #7)
> I agree that this wouldn't affect valid C11 code (because of data-races) but
> my understanding is that __sync builtins don't require a C11 model. The
You say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #7 from Matthew Wahab ---
(In reply to torvald from comment #5)
> (In reply to Matthew Wahab from comment #0)
> > The __sync builtins are implemented by expanding them to the equivalent
> > __atomic builtins, using MEMMODEL_SEQ_CST fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to torvald from comment #5)
> (In reply to Matthew Wahab from comment #0)
> > while a __sync full
> > barrier should block all movement
> > (https://gcc.gnu.org/onlinedocs/gcc/_005f_005f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #5 from torvald at gcc dot gnu.org ---
(In reply to Matthew Wahab from comment #0)
> The __sync builtins are implemented by expanding them to the equivalent
> __atomic builtins, using MEMMODEL_SEQ_CST for those that are full barriers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #4 from Matthew Wahab ---
There is a difference between __syncs and __atomics, assuming the the __atomics
are meant to match the C11/C++11 memory model. With C11 atomics, a barrier for
an operation on an object only affects memory ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #1 from Matthew Wahab ---
I'm working on this but it isn't obvious how to fix it. The strong barriers
aren't needed for the __atomics and will have an effect on performance so
simply strengthening the MEMMODEL_SEQ_CST implementation i
74 matches
Mail list logo
