[LLVMdev] [cfe-dev] llvm (hence Clang) not compiling with Visual Studio 2008

Ahmed Bougacha ahmed.bougacha at gmail.com
Thu Jul 4 16:43:13 PDT 2013


On Thu, Jul 4, 2013 at 12:48 AM, Benoit Perrot
<benoit.noe.perrot at gmail.com>wrote:

> Hello,
>

Hi Benoit,


> I have just updated my svn copy of the llvm/clang repositories after quite
> a long time of inactivity, and found it not compiling on Windows with
> Visual Studio 2008.
>
> The incriminated file is:
>
>   llvm/lib/MC/MCModule.cpp
>
> Where several calls to "std::lower_bound" are made, like:
>
>   atom_iterator I = std::lower_bound(atom_begin(), atom_end(),
>                                      Begin, AtomComp);
>
> With:
>   - "atom_iterator" being a typedef on "std::vector<llvm::Atom*>::iterator"
>   - "atom_begin()" and "atom_end" returning an "atom_iterator"
>   - "Begin" being an "uint64_t"
>   - "AtomComp" being a predicate of type "bool (const llvm::MCAtom
> *,uint64_t)"
>
> This seems to be due to an invalid implementation of the STL as provided
> with Visual Studio 2008.
>
> Indeed, the predicate given to "lower_bound" must respect the following
> rules:
>
>   - obviously, it shall return "bool" (here: of course)
>
>    - its first argument shall be of a type into which the type of the
> dereferenced iterators can be implicitly converted (here:
> "atom_iterator::operator*" returns a "llvm::Atom*", and the first argument
> of "AtomComp" is also "llvm::Atom*"
>
>   - its second argument shall be of a type into which the type of the
> value can be implicitly converted (here: "Begin" is an "uint_64_t", as well
> as the second argument of "AtomComp")
>
> But the implementation of "std::lower_bound" in Visual Stuio 2008 relies
> on a checker provided by the file "xutility", which reads:
>
> template<class _Pr, class _Ty1, class _Ty2> inline
> bool __CLRCALL_OR_CDECL _Debug_lt_pred(_Pr _Pred,
>                                        _Ty1& _Left,
>                                        const _Ty2& _Right,
>                                        const wchar_t *_Where,
>                                        unsigned int _Line)
> { // test if _Pred(_Left, _Right) and _Pred is strict weak ordering
>
>   if (!_Pred(_Left, _Right))
>     return (false);
>   else if (_Pred(_Right, _Left))
>     _DEBUG_ERROR2("invalid operator<", _Where, _Line);
>
>   return (true);
> }
>
>  Hence, it expects the predicate (here "_Pred") to accept as arguments
> both (_Ty1, _Ty2) and (_Ty2, _Ty1), which does not seem consistent with the
> specifications mentioned above.
>
> Solutions here:
>
> 1. consider that the implementation if effectively wrong, and modify the
> documentation at http://llvm.org/docs/GettingStartedVS.html, requiring
> Visual Studio 2010, i.e. replacing:
>
>    "You will need Visual Studio 2008 or higher."
>
>    by:
>
>    "You will need Visual Studio 2010 or higher."
>
>    Same comments on the respect of the standard apply
>
> 2. investigate whether there exists a way to disable the aforementioned
> check;
>
> 3. modify the code in MCModule.cpp to cope with the implementation of
> "lower_bound" in VS 2008.
>
> Personally I just went for (1), i.e. switching to Visual Studio 2010, as
> it was the most straightforward.
>

(3) Fixed in r185676.

Requiring VS 2010 for a minor problem like this (even though there are more
like it) isn’t warranted I think.

Doing so, I also had to add "#include <string>" to the file
> "lib/CodeGen/CGBlocks.cpp" so that llvm/clang can compile with said
> compiler, because of some obscure external template usage.
>

<string> is already included, at least by StringRef.h, so I’m curious: what
is this obscure thing that needs including it again?

Thanks,

-- Ahmed Bougacha


> Regards,
> --
> Benoit PERROT
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/cb0a7c4e/attachment.html>


More information about the llvm-dev mailing list