[cfe-dev] clang fails to compile gcc 4.8's <unordered_map>

Chandler Carruth chandlerc at google.com
Thu May 31 08:50:45 PDT 2012


On Thu, May 31, 2012 at 8:44 AM, Howard Hinnant <hhinnant at apple.com> wrote:

> On May 31, 2012, at 5:18 AM, Chandler Carruth wrote:
>
> > On Thu, May 31, 2012 at 2:15 AM, Sebastian Redl <
> sebastian.redl at getdesigned.at> wrote:
> > On 31.05.2012 05:59, Nathan Ridge wrote:
> > > The problem is that GCC uses the following alias template as class
> scope:
> > >
> > > template<typename _Pair>
> > > using __is_convertible = std::is_convertible<_Pair, value_type>;
> > >
> > > but __is_convertible, I am guessing, is a compiler intrinsic in clang.
> > >
> > > Is either gcc or clang doing something wrong, or is it just a clash of
> implementations?
> > It's a clash of implementations. We've had this before, but not with a
> > new GCC version - only with old GCC versions.
> > > What can be done to resolve this?
> > >
> > Since GCC 4.8 is not yet released, and Clang versions with the
> > __is_convertible intrinsic are, the best solution would be to politely
> > ask the libstdc++ maintainers to change this name.
> >
> > Please let us know if you do / what the PR is for it? We're likely to
> hit this as well, and will want to track the progress of getting it
> resolved.
>
> This looks fixable on the clang side to me.  The clang intrinsic
> __is_convertible is currently undocumented:
>
> http://clang.llvm.org/docs/LanguageExtensions.html#checking_type_traits
>
> However we document __is_convertible_to
>
> int main()
> {
>    static_assert(__is_convertible(int, long), "");
>    static_assert(__is_convertible_to(int, long), "");
> }
>
> I imagine __is_convertible was left in to give time for things like libc++
> to migrate to __is_convertible_to.  It has.  Why don't we just dump
> __is_convertible.
>

We can certainly do this (and probably should) but it doesn't fix released
versions of Clang... so my preference would be to still change libstdc++
prior to the next GCC release in order to have as much
inter-version/toolchain compatibility as we can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120531/48380c1c/attachment.html>


More information about the cfe-dev mailing list