<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 10, 2012, at 4:24 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I want to call out this point:<div><br><div class="gmail_quote">On Wed, Apr 11, 2012 at 12:25 AM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote>
</div><br></div><div>I think this is setting ourselves up for an endless game of catchup. What is worse, our users will suffer.</div><div><br></div><div>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.</div></blockquote><div><br></div><div>We *are* in an endless game of catch-up, regardless of what we do with atomics. GCC is still the dominant vendor on most platforms we care about, and in every release they introduce something to libstdc++---whether it is the use of some newly-invented intrinsic, or incorrect use of C++11, or whatever---that requires us to implement new features or workarounds. That won't change unless we work with the GCC community more closely.</div><div><br></div><div>But I do agree that introducing wrapper headers is a poor solution.</div><br><blockquote type="cite"><div>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.</div>
<div><br></div><div>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.</div></blockquote><div><br></div>I agree with this.</div><div><br><blockquote type="cite"><div>While a realize this isn't ideal, and it requires renaming currently supported intrinsics I see few options left to us:</div><div>1) We haven't released with these intrinsics</div><div>2) GCC has released with its intrinsics</div>
<div>3) We failed to discuss our intrinsics sufficiently with the GCC folks to get them to implement the same set</div><div>4) GCC folks failed to discuss theirs with us sufficiently to get us to implement the same set</div>
<div>5) We need something for Clang v3.1, or it is instantly un-usable with GCC 4.7 and later.</div><div><br></div><div>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.</div></blockquote><br></div><div>First order of business is to get the intrinsics renamed in Clang and libc++. Since Clang's intrinsics directly relate to C11's facilities, and it's vendor-neutral, I prefer the __c11_* naming. Who will make this change?</div><div><br></div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>- Doug</div><br></body></html>