https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Jakub Jelinek changed:
What|Removed |Added
CC||matt at bitbashing dot io
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #16 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 4 12:27:08 2016
New Revision: 232052
URL: https://gcc.gnu.org/viewcvs?rev=232052=gcc=rev
Log:
PR c/68908
* c-typeck.c (build_atomic_assign): Improve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #15 from joseph at codesourcery dot com ---
Note that we also have bug 64843 for atomic_fetch_* on pointers (with a
suggested approach for how stdatomic.h could handle the multiplication by
the pointer target size).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #14 from Marek Polacek ---
(In reply to Martin Sebor from comment #13)
> (In reply to Marek Polacek from comment #10)
>
> C doesn't allow the atomic_fetch_xxx operations to be used with the
> atomic_bool type (it says they're "not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #10 from Marek Polacek ---
While working on this, I've found something weird, as shown in the following
testcase:
int
main (void)
{
_Atomic _Bool a = 1;
__builtin_printf ("%d\n", a);
__atomic_fetch_add (, 1, __ATOMIC_SEQ_CST);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #12 from Marek Polacek ---
Okay, thanks, with other types the optimization seems to work (yay!).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #13 from Martin Sebor ---
(In reply to Marek Polacek from comment #10)
C doesn't allow the atomic_fetch_xxx operations to be used with the atomic_bool
type (it says they're "not applicable" without spelling what that means, but
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #11 from Jakub Jelinek ---
IMHO you should use the current code for _Bool atomic increments/decrements,
_Bool has just doesn't behave like an integer.
Only normal integers (with the precision the same as mode's precision, properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #6 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #2)
> Doesn't seem to be ppc64le specific in any way, and doesn't affect just
> preincrement.
The inefficiency I was pointing out was the redundant syncs above the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Henderson from comment #4)
> I think we should rather handle this in the front end than with
> quite complex pattern matching.
>
> If we want to do any complex logic with atomics in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #8 from joseph at codesourcery dot com ---
I'm fine with making the front end smarter. Note that if either side of
the assignment is of floating-point type, you need to keep the existing
logic; if you're adding to / subtracting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Marek Polacek changed:
What|Removed |Added
Component|target |c
--- Comment #5 from Marek Polacek
14 matches
Mail list logo
