On 01/14/2015 01:28 PM, Joseph Myers wrote:
On Wed, 14 Jan 2015, Andrew MacLeod wrote:
- There is a warning for invalid memory models already, so I just continued
using that.
- I remove the check for CONSUME in exchange since the current standard makes
no mention of that being illegal.
- I also
On Wed, 14 Jan 2015, Andrew MacLeod wrote:
> - There is a warning for invalid memory models already, so I just continued
> using that.
> - I remove the check for CONSUME in exchange since the current standard makes
> no mention of that being illegal.
> - I also reversed the current check in compar
On 01/13/2015 05:37 PM, Joseph Myers wrote:
On Tue, 13 Jan 2015, Andrew MacLeod wrote:
It seems that it should be safe to move back to the original patch, and remove
that error test for using consume on an exchange...
I don't think there should be any such errors, for any of the atomic
built-i
On Wed, 2015-01-14 at 10:44 -0500, Andrew MacLeod wrote:
> I think this brings us to where we ought to be... at least almost :-)
> The latest version I have is n3337, which still specifies that
> atomic_clear can't be memory_order_acquire or memory_order_acq_rel. Has
> that been updated to spe
On 01/13/15 15:56, Andrew MacLeod wrote:
On 01/13/2015 02:06 PM, Andrew MacLeod wrote:
On 01/13/2015 01:38 PM, Torvald Riegel wrote:
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
On 01/13/2015 09:59 AM, Richard Biener wrote:
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod
wrote:
On 01/13/2015 02:06 PM, Andrew MacLeod wrote:
On 01/13/2015 01:38 PM, Torvald Riegel wrote:
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
On 01/13/2015 09:59 AM, Richard Biener wrote:
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod
wrote:
Lengthy discussion :
https://gcc.gnu.org/b
On Tue, 13 Jan 2015, Andrew MacLeod wrote:
> It seems that it should be safe to move back to the original patch, and remove
> that error test for using consume on an exchange...
I don't think there should be any such errors, for any of the atomic
built-in functions, only warnings (with the model
On 01/13/2015 01:38 PM, Torvald Riegel wrote:
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
On 01/13/2015 09:59 AM, Richard Biener wrote:
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Basically we can
On 01/13/15 11:38, Torvald Riegel wrote:
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
On 01/13/2015 09:59 AM, Richard Biener wrote:
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Basically we can gene
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
> On 01/13/2015 09:59 AM, Richard Biener wrote:
> > On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
> >> Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
> >>
> >> Basically we can generate incorrect code for an
On 01/13/2015 10:20 AM, Torvald Riegel wrote:
On Tue, 2015-01-13 at 09:56 -0500, Andrew MacLeod wrote:
The problem with the patch in the PR is the memory model is immediately
promoted from consume to acquire. This happens *before* any of the
memmodel checks are made. If a consume is illegall
On Tue, 2015-01-13 at 09:56 -0500, Andrew MacLeod wrote:
> The problem with the patch in the PR is the memory model is immediately
> promoted from consume to acquire. This happens *before* any of the
> memmodel checks are made. If a consume is illegally specified (such as
> in a compare_exch
On 01/13/2015 09:59 AM, Richard Biener wrote:
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Basically we can generate incorrect code for an atomic consume operation in
some circumstances. The general feeling seem
On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
> Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
>
> Basically we can generate incorrect code for an atomic consume operation in
> some circumstances. The general feeling seems to be that we should simply
> promote al
Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Basically we can generate incorrect code for an atomic consume operation
in some circumstances. The general feeling seems to be that we should
simply promote all consume operations to an acquire operation until
there is a
15 matches
Mail list logo