Re[2]: [Gc] Should libatomic_ops be inside bdwgc?

Ivan Maidanski ivmai at
Thu Aug 18 00:17:27 PDT 2011

Hi Petter,

Thank you for the explanation. But my Q was really about operations set not about types width to be supported.


18 08 2011, 11:04 Petter Urkedal <urkedal at>:
> On 2011-08-17, Ivan Maidanski wrote:
> > Hi Petter and Hans,
> >
> > Is the current libatomic_ops API sufficient to implement the complete C++0x atomics API? (Or, we don't need to implement all the C++0x primitives, do we?)
> I can answer part of that question.  The AO_t may be to narrow to
> implement all the atomic_X_t types.  In the ISO/IEC:TC2 draft which I'm
> using as my C99 reference, the corresponding stdint.h are optional
> (
>     These types are optional. However, if an implementation provides
>     integer types with widths of 8, 16, 32, or 64 bits, no padding bits,
>     and (for the signed types) that have a two’s complement
>     representation, it shall define the corresponding typedef names.
> Not sure if that changed in the final standard.  On the other hand N1349
> does not state that the atomic_X_t types are optional, but since my
> reference[1] is a proposal, that may change.
> In any case, I think it'll suffice for our purpose to only implement up
> to the word size.  In the long run the stdatomic.h header will be
> shipped by the compiler vendor anyway.
> > A sub-question: what's about CAS? I mean do we need a CAS variant returning old-value to implement the corresponding C++0x primitive?
> [1]
> _______________________________________________
> Gc mailing list
> Gc at

More information about the Gc mailing list