[cfe-dev] [LLVMdev] pinging 18097: atomic<> of trivially copyable class is rejected

[Richard Smith]

On Wed, Jul 16, 2014 at 5:46 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> 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
>
> ----- Original Message -----
> > From: "Tim Blechmann" <tim at klingt.org>
> > To: llvmdev at cs.uiuc.edu
> > Sent: Sunday, July 13, 2014 5:32:01 AM
> > Subject: *****SPAM*****[LLVMdev] 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
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140716/ddec8ee4/attachment.html>