On 07/26/2013 07:21 PM, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
This patch adds an atomic type qualifier to GCC. It can be accessed via
__attribute__((atomic)) or in C11 mode via the _Atomic keyword.
Why the attribute - why not just the keyword?
* When C11 refers
On 07/30/2013 09:44 AM, Andrew MacLeod wrote:
On 07/30/2013 09:16 AM, Joseph S. Myers wrot
THis also means that for the 3 floating point operations all we need
are RTL
insn patterns, no buitin. And as with the other atomics, if the
pattern
I think something will also be needed to specify
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Ive been poking at this today, and Im wondering what you think of the idea of
adding a flag to MODIFY_EXPR,
#define MODIFY_EXPR_IS_COMPOUND(NODE)
MODIFY_EXPR_CHECK(NODE)-base.asm_written_flag
and set that in the MODIFY_EXPR node when we create it
On 07/30/2013 07:41 AM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Ive been poking at this today, and Im wondering what you think of the idea of
adding a flag to MODIFY_EXPR,
#define MODIFY_EXPR_IS_COMPOUND(NODE)
MODIFY_EXPR_CHECK(NODE)-base.asm_written_flag
and set
On Tue, 30 Jul 2013, Andrew MacLeod wrote:
A flag on the expression could indicate that the floating-point semantics
are required. I'd guess back ends would need to provide three insn
patterns, corresponding to feholdexcept, feclearexcept and feupdateenv,
that there'd be corresponding
On 07/30/2013 09:16 AM, Joseph S. Myers wrot
My reasoning for such a flag is:
Hence my suggestion that the operands to the new built-in function /
operation do not include the unmodified RHS, and do not directly specify
the operation in question. Instead, one operand is an expression of the
On 07/28/2013 03:34 PM, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
What it doesn't do:
* It doesn't implement the stdatomic.h header - do you intend that to be
provided by GCC or glibc?
(Substantive review of the full patch still to come.)
I figured gcc would provide
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Blick. What were they smoking the night before... I guess we'll probably need
to enhance the current atomic patterns in RTL...We should be able to
figure out that its floating point and invoke the appropriate RTL pattern
during expansion rather
On 07/29/2013 10:59 AM, Andrew MacLeod wrote:
Blick. What were they smoking the night before... I guess we'll
probably need to enhance the current atomic patterns in RTL...We
should be able to figure out that its floating point and invoke the
appropriate RTL pattern during expansion rather
On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Blick. What were they smoking the night before... I guess we'll probably need
to enhance the current atomic patterns in RTL...We should be able to
figure out that its floating point and invoke the
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
complex I hadn't thought about until just now, I'll have to look. I know we
can deal with parts on complex sometimes. Hopefully at gimplification time
we still have the whole complex reference and if we just take care of that
with the atomic
On 07/29/2013 12:42 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
complex I hadn't thought about until just now, I'll have to look. I know we
can deal with parts on complex sometimes. Hopefully at gimplification time
we still have the whole complex reference and if
On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
I planned to do the work in gimplification... let the atomic decls through,
and during gimplification, loads or stores of an atomic decl would be
converted to the appropriate load or store builtin, and at
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
What it doesn't do:
* It doesn't implement the stdatomic.h header - do you intend that to be
provided by GCC or glibc?
(Substantive review of the full patch still to come.)
* It doesn't implement the C11 expression expansion into atomic
Andrew MacLeod amacl...@redhat.com writes:
What it doesn't do:
* It doesn't implement the C11 expression expansion into atomic
built-ins. ie, you can't write:
_Atomic int x;
x = 0;
and have the result be an atomic operation calling
__atomic_store (x, 0).
How would this work
On 07/26/2013 03:01 PM, Andi Kleen wrote:
Andrew MacLeod amacl...@redhat.com writes:
What it doesn't do:
* It doesn't implement the C11 expression expansion into atomic
built-ins. ie, you can't write:
_Atomic int x;
x = 0;
and have the result be an atomic operation calling
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
This patch adds an atomic type qualifier to GCC. It can be accessed via
__attribute__((atomic)) or in C11 mode via the _Atomic keyword.
HP, you might want to give this a try and see if you can get the alignment
correct for the cris port finally :-)
Andrew MacLeod amacl...@redhat.com writes:
The way the standard is defined, any implicit operation like that is
seq_cst. If you want something other than seq-cst, you have to
explicitly call atomic_store (x, 0, model).
Thanks.
This doesn't sound like a good default for x86. seq_cst requires
On 07/26/2013 05:13 PM, Andi Kleen wrote:
Andrew MacLeod amacl...@redhat.com writes:
The way the standard is defined, any implicit operation like that is
seq_cst. If you want something other than seq-cst, you have to
explicitly call atomic_store (x, 0, model).
Thanks.
This doesn't sound like
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
This patch adds an atomic type qualifier to GCC. It can be accessed via
__attribute__((atomic)) or in C11 mode via the _Atomic keyword.
Why the attribute - why not just the keyword?
I'll review the patch in detail later (which will involve checking
On 07/26/2013 07:21 PM, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
This patch adds an atomic type qualifier to GCC. It can be accessed via
__attribute__((atomic)) or in C11 mode via the _Atomic keyword.
Why the attribute - why not just the keyword?
2 reasons:
1 -
21 matches
Mail list logo
