<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Le 11 avr. 2012 à 02:08, Chandler Carruth a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Wed, Apr 11, 2012 at 1:03 AM, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="HOEnZb"><div class="h5">On Apr 10, 2012, at 7:59 PM, Howard Hinnant wrote:<br>
<br>
> On Apr 10, 2012, at 7:24 PM, Chandler Carruth wrote:<br>
><br>
>> I want to call out this point:<br>
>><br>
>> On Wed, Apr 11, 2012 at 12:25 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> 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.<br>
>><br>
>> I think this is setting ourselves up for an endless game of catchup. What is worse, our users will suffer.<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> While a realize this isn't ideal, and it requires renaming currently supported intrinsics I see few options left to us:<br>
>> 1) We haven't released with these intrinsics<br>
>> 2) GCC has released with its intrinsics<br>
>> 3) We failed to discuss our intrinsics sufficiently with the GCC folks to get them to implement the same set<br>
>> 4) GCC folks failed to discuss theirs with us sufficiently to get us to implement the same set<br>
>> 5) We need something for Clang v3.1, or it is instantly un-usable with GCC 4.7 and later.<br>
>><br>
>> 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.<br>
><br>
> Perhaps we need to stake out another namespace for clang atomic intrinsics. Our current prefix is:<br>
><br>
> __atomic_<br>
><br>
> Suggestions:<br>
><br>
> __clang_atomic_<br>
> __clng_atmc_<br>
> _ClangAtomic_<br>
> _CLNGatomic_<br>
> _CLNG_ATM_<br>
> _ClngAtm_<br>
><br>
> The final suggestion has the same length as our current prefix.<br>
<br>
<br>
</div></div>Or even shorter: :-)<br>
<br>
__atomx_<br></blockquote><div><br></div><div>I am quite lazy when it comes to typing, but perhaps here is not the time to save characters. ;] I would vote:</div><div><br></div><div>__clang_atomic_</div><div><br></div></div></blockquote><div><br></div><div>The prefix length should not be an issue.</div><div>As David said, these builtins should be reserved to implement <stdatomic.h> and <atomic>, so should never have to call them explicitly.</div><br><blockquote type="cite"><div class="gmail_quote"><div>
or, based on the discussion between David and Richard, perhaps:</div><div><br></div><div>__c11_atomic_</div><div><br></div><div>to call out their close correspondance with the c11 spec.</div></div></blockquote><br></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>-- Jean-Daniel</div><div><br></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>