[cfe-dev] RFC: __atomic_* support for gcc 4.7 compatibility

Tue Apr 10 17:47:25 PDT 2012

You folks do all the heavy lifting and thus are fully/well versed in the 
syntax and phonetics of the grammar you choose, but to put it bluntly if 
English became a chicken scratch language it never would have developed 
fully [though other languages would challenge that fully developed 
assertion on my part].

*__clang_atomic_* is clearly readable and discernible, and I could care 
less about saving a few bytes in characters. Most editors can also make 
custom tags that trigger the entire string with a simple combination of 
key-strokes for an action to be performed.

This is one of the reasons I personally have a love/hate relationship 
with Computer Science and another reason Mechanical Engineering is my 
first and more beloved degree.

It's also another reason I was glad to work at NeXT and Apple with the 
knowledge that Objective-C is such a readable programming language, 
unlike the chicken scratch often found in C/C++.

Sincerely,

- Marc J. Driftmeyer

On 04/10/2012 05:08 PM, Chandler Carruth wrote:
> On Wed, Apr 11, 2012 at 1:03 AM, Howard Hinnant <hhinnant at apple.com 
> <mailto:hhinnant at apple.com>> wrote:
>
>     On Apr 10, 2012, at 7:59 PM, Howard Hinnant wrote:
>
>     > On Apr 10, 2012, at 7:24 PM, Chandler Carruth wrote:
>     >
>     >> I want to call out this point:
>     >>
>     >> On Wed, Apr 11, 2012 at 12:25 AM, Richard Smith
>     <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>     >> This approach, including the need to interpose in front of
>     <atomic> and <shared_ptr> (and any other user of the atomics
>     builtins in libstdc++) and detect whether we're about to include a
>     header from libstdc++, seems sufficiently fragile that I'm still
>     in favour of introducing GNU-compatible builtins.
>     >>
>     >> I think this is setting ourselves up for an endless game of
>     catchup. What is worse, our users will suffer.
>     >>
>     >> Version skew between libstdc++ and Clang is inevitable. As a
>     consequence, the advantages of being maximally compatible with
>     libstdc++ are only present when we can be largely *forward*
>     compatible. This seems impossible if we have to intercept ever
>     header to reference a GCC builtin and introduce our wrapper for it.
>     >>
>     >>
>     >> At a fundamental level, I am not yet comfortable with Clang,
>     after defining __GNUC__ and acting as a heavily compatible
>     compiler with GCC, going on to define builtin functions which
>     share the same name but incompatible semantics with GCC builtins.
>     This seems like a recipe for a long string of puzzling compilation
>     failures, user frustration, and impeded adoption of Clang.
>     >>
>     >> I think we should continue with the long standing policy of,
>     when reasonable and tenable, supporting the GCC builtins with
>     their names, and allowing users to not care. Then, under a
>     *different* naming pattern, and guarded by proper __has_feature
>     macros etc, we should provide Clang-specific extensions which have
>     the semantics we would rather see.
>     >>
>     >> While a realize this isn't ideal, and it requires renaming
>     currently supported intrinsics I see few options left to us:
>     >> 1) We haven't released with these intrinsics
>     >> 2) GCC has released with its intrinsics
>     >> 3) We failed to discuss our intrinsics sufficiently with the
>     GCC folks to get them to implement the same set
>     >> 4) GCC folks failed to discuss theirs with us sufficiently to
>     get us to implement the same set
>     >> 5) We need something for Clang v3.1, or it is instantly
>     un-usable with GCC 4.7 and later.
>     >>
>     >> I don't like any of this, and it isn't how I would wish for
>     things to proceed if I had it to do again, but this is where we
>     are. We need to realize that, today, I cannot compile any
>     meaningful C++98 code with the default C++ standard library on
>     Linux (after a distro picks up GCC 4.7) and Clang. I do not think
>     that is an acceptable state to release Clang under.
>     >
>     > Perhaps we need to stake out another namespace for clang atomic
>     intrinsics.  Our current prefix is:
>     >
>     > __atomic_
>     >
>     > Suggestions:
>     >
>     > __clang_atomic_
>     > __clng_atmc_
>     > _ClangAtomic_
>     > _CLNGatomic_
>     > _CLNG_ATM_
>     > _ClngAtm_
>     >
>     > The final suggestion has the same length as our current prefix.
>
>
>     Or even shorter: :-)
>
>     __atomx_
>
>
> I am quite lazy when it comes to typing, but perhaps here is not the 
> time to save characters. ;] I would vote:
>
> __clang_atomic_
>
> or, based on the discussion between David and Richard, perhaps:
>
> __c11_atomic_
>
> to call out their close correspondance with the c11 spec.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120410/76fb10aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120410/76fb10aa/attachment.vcf>