Date: Fri, 21 Oct 2016 17:21:33 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Willem Jan Withagen <wjw@digiware.nl> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: Seeking help with some Clang trouble, compiling ceph Message-ID: <8DCCD19E-01EE-4DB4-814E-396D3E450275@FreeBSD.org> In-Reply-To: <7b6713f1-5671-bdc2-9cb5-97171146bc59@digiware.nl> References: <c88fd975-b379-ac79-0979-03407565781a@digiware.nl> <7b6713f1-5671-bdc2-9cb5-97171146bc59@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 21 Oct 2016, at 17:07, Willem Jan Withagen <wjw@digiware.nl> wrote: > > On 21-10-2016 15:09, Willem Jan Withagen wrote: >> Hi, >> >> All this Ceph stuff finally used to compile under FreeBSD. >> And all testss completed correctly. >> >> But somewhere in the Ceph-tree there was a lot of template and trait >> code added/replaced. >> Problem is that this compiles under GCC, but Clang throws an error. It >> looks like it cannot select types of automagic conversion. >> >> But this template/trait stuff is too much for me to wrap my head around. >> I'm reading up a lot, but that does not yet get me anywhere. >> >> So I was wondering if anybody with more C++ knowledge would like to >> assist and give some clues as to how to fix this. >> >> The error report is at: >> >> http://cephdev.digiware.nl:8180/jenkins/job/ceph-freebsd/39/consoleFull >> >> And the ceph code can be found at: >> https://github.com/ceph/ceph > > Oke, the preson responsable for the change helped to figure it out, and > it looks like the following diff helps > > diff --git a/src/include/denc.h b/src/include/denc.h > index 59f7686..caa095b 100644 > --- a/src/include/denc.h > +++ b/src/include/denc.h > @@ -722,7 +722,7 @@ struct denc_traits< > template<typename T> > struct denc_traits< > std::vector<T>, > - typename std::enable_if<denc_traits<T>::supported>::type> { > + typename std::enable_if<denc_traits<T>::supported != 0>::type> { > typedef denc_traits<T> traits; > > enum { supported = true }; > @@ -831,7 +831,7 @@ struct denc_traits< > template<typename T> > struct denc_traits< > std::set<T>, > - typename std::enable_if<denc_traits<T>::supported>::type> { > + typename std::enable_if<denc_traits<T>::supported != 0>::type> { > typedef denc_traits<T> traits; > > enum { supported = true }; > > And the conclusion is that std::enable_if<> does not always like it when > the value is 'int'. > the definition of supported is: > struct denc_traits { > enum { supported = 0 }; > enum { featured = false }; > enum { bounded = false }; > }; > > and values can range 0..2. > > So is this a GCC liberalization, or is Clang here to picky? It's hard to say without the full source code and a reproducer, but I'd say that enable_if has a bool as the first template argument, so it can't match an int by default. Maybe libstdc++ has a variant with an int as the first template argument, but I haven't looked. -Dimitry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlgKMoQACgkQsF6jCi4glqPyrQCfT0p4RIyxgizAkmyevxCXXxM3 K58AoNtI56lg3AWLSj7H1p+tCQbqAlqH =p0uR -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8DCCD19E-01EE-4DB4-814E-396D3E450275>