pinging 18097: atomic<> of trivially copyable class is rejected

hi all,

bug 18097 has already been discussed on this list more than a year ago,
and it is open with a patch attached since last autumn ... despite being
tagged as release blocker. is there any estimation when this issue will
be fixed?

tia,
tim

Weird that it wasn't resolved if it was tagged as a release blocker.

Apart from that, patches on bugs tend not to get attention. If this
matters to you (especially if you're the patch's original author) the
patch should be sent to the appropriate -commits list and pinged
weekly.

Weird that it wasn't resolved if it was tagged as a release blocker.

Apart from that, patches on bugs tend not to get attention. If this
matters to you (especially if you're the patch's original author) the
patch should be sent to the appropriate -commits list and pinged
weekly.

the patch is not mine, but has been provided by howard hinnant. however
bill wendling asked richard and doug if it should be fixed in clang or
in libc++. that was the end of the discussion.

Tim,

I'm moving this to cfe-dev (this is a frontend issue). When pinging an issue, it helps to provide a brief synopsis of the problem...

Looking at this briefly, the question seems to center on whether clang should support converting from T to _Atomic(T) for non-POD (but trivially copyable) types. Currently it does not, but the libc++ implementation of atomic<T> is based on _Atomic(T) and inherits this restriction, rendering it non-conforming. Howard had created a libc++ patch to change the implementation of atomic<T> so that it was not directly based on _Atomic(T), but noted that a clang change could also fix the issue. Looking at Howard's patch, I can understand his hesitation (it certainly makes the implementation more complicated).

-Hal

Tim,

I'm moving this to cfe-dev (this is a frontend issue). When pinging an
issue, it helps to provide a brief synopsis of the problem...

Looking at this briefly, the question seems to center on whether clang
should support converting from T to _Atomic(T) for non-POD (but trivially
copyable) types. Currently it does not, but the libc++ implementation of
atomic<T> is based on _Atomic(T) and inherits this restriction, rendering
it non-conforming. Howard had created a libc++ patch to change the
implementation of atomic<T> so that it was not directly based on
_Atomic(T), but noted that a clang change could also fix the issue. Looking
at Howard's patch, I can understand his hesitation (it certainly makes the
implementation more complicated).

As I understand things, the intent was that it should be possible to

  #define _Atomic(T) std::atomic<T>

when using C headers from C++ programs, and that level of equivalence would
naturally extend to imply that _Atomic(T) should allow non-POD but
trivially-copyable types in the cases where std::atomic<T> does. Further, I
think any checking of whether a type is POD is essentially a mistake: the
notion of POD has been nearly entirely expunged from the C++ language at
this point.

So... my preference is to fix this in Clang. I think we're just missing the
relevant initialization (and probably overload resolution) code to allow
initiailzation of _Atomic(T) from T in these cases.

-Hal