This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add atomic type qualifier
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, hp at bitrange dot com, Richard Henderson <rth at redhat dot com>
- Date: Tue, 30 Jul 2013 09:44:09 -0400
- Subject: Re: [PATCH] Add atomic type qualifier
- References: <51F2AEB1 dot 60408 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307281928000 dot 28065 at digraph dot polyomino dot org dot uk> <51F6836F dot 6080400 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307291553330 dot 12248 at digraph dot polyomino dot org dot uk> <51F6F4EE dot 20902 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307301124520 dot 8733 at digraph dot polyomino dot org dot uk> <51F7B0D8 dot 8040509 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307301306080 dot 8733 at digraph dot polyomino dot org dot uk>
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
(convert-to-LHS-type) (old op val)
where "old" and "val" are the temporary variables given in C11 footnote
113 and probably allocated by the front end ("val" initialized once, "old"
initialized once but then potentially changing each time through the
loop). The trees for that expression would be generated by
build_binary_op and contain everything required for the semantics of e.g.
It's true that in the case where floating-point issues arise,
floating-point types will be involved somewhere in this expression (and
otherwise, they will not be - though the initializer for "val" might
itself have involved floating-point arithmetic), but you'd need to search
recursively for them; having a flag seems simpler.
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 allocation of the fenv_t
temporary (whether in memory or registers).
doesnt exist, we just wont emit it. we could add a warning easily enough in
Note there's a difference between no need to emit it, no warning should be
given (soft float) and need to emit it but patterns not yet written so
warning should be given (hard float but patterns not yet implemented for
In fact, the flag could be the presence of the fenv_t variable.. Null
for that variable field in the builtin indicate you don't need the
I';ll get back to you in a bit with the actual built-in's format once I
poke around the existing one and see how I can leverage it. I rewrote
all that code last year and it ought to be pretty simple to add new
operand support. It better be anyway :-)