[cfe-dev] Using clang to parse C++ on Windows
Jesper Eskilson
jesper.eskilson at iar.com
Wed Oct 30 04:45:09 PDT 2013
On 10/29/2013 10:06 PM, Richard Smith wrote:
> On Tue, Oct 29, 2013 at 7:37 AM, Jesper Eskilson
> <Jesper.Eskilson at iar.com <mailto:Jesper.Eskilson at iar.com>> wrote:
>
>
> Hi,
>
> I've gotten stuck on a weird error message from Clang. I'm writing a
> Clang-based tool to analyze legacy C++ source code. The code relies
> heavily on Windows-specific headers files (MFC, etc) and I have
> never been able to get Clang to properly parse MS own header files.
> Running the tool on Linux works fine; I've created a set of dummy
> replacement header files which are complete enough to allow Clang to
> build a usable AST for me. However, running the tool on Windows
> turns out to be more difficult than I thought.
>
> I've tried several approaches as to what header files should be
> used. Clang was never able to get through the MS header files
> without crashing or producing various errors. Since the tool worked
> fine on Linux, I imagined that it should be possible to use Linux
> header files instead. This got me pretty far, but now I've gotten
> stuck on an error which I cannot make sense of.
>
>> $ clang -fno-ms-extensions -D_GNU_SOURCE -c foo.cpp -isystem
>> ./linux-glibc/include -isystem ./linux-glibc/include/c++/4
>> .7 -isystem ./linux-glibc/include/c++/4.7/bits -isystem
>> linux-glibc/include/c++/4.7/x86_64-linux-gnu
>> In file included from foo.cpp:1:
>> In file included from ./linux-glibc/include/c++/4.7\vector:63:
>> In file included from
>> ./linux-glibc/include/c++/4.7\bits/stl_construct.h:63:
>> In file included from
>> ./linux-glibc/include/c++/4.7\ext/alloc_traits.h:35:
>> ./linux-glibc/include/c++/4.7\bits/alloc_traits.h:56:35: error:
>> in-class initializer for static data member is not a
>> constant expression
>> static const bool __value = _S_chk<_Alloc, _Tp>(nullptr);
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> At a guess, clang is implicitly running in -fdelayed-template-parsing
> mode, and this is failing because _S_chk<...> is a constexpr function
> template specialization that has not been parsed yet. That's a bug that
> was fixed recently.
>
> What target triple is clang using? IIRC we only turn on
> -fdelayed-template-parsing in MSVC-compatibility mode, but it looks like
> you're going for something more like a mingw target. (libstdc++ probably
> won't work in MSVC-compatibility mode.)
>
i686-pc-win32. Also, I'm specifying -fdelayed-template-parsing
explicitly in order to get some of the legacy C++ sources through the
parser.
I managed to get around this by brutally removing the initialization in
alloc_traits.h. Since I have my own copy of the header files, this is ok
for me at the moment. At some point, however, it would be nice if clang
could just use Microsofts own header files.
Thanks!
>> ./linux-glibc/include/c++/4.7\bits/alloc_traits.h:63:19: note: in
>> instantiation of template class
>> 'std::__alloctr_rebind_helper<std::allocator<int>, int>'
>> requested here
>> bool = __alloctr_rebind_helper<_Alloc, _Tp>::__value>
>> ^
>> ./linux-glibc/include/c++/4.7\bits/alloc_traits.h:201:9: note: in
>> instantiation of default argument for
>> '__alloctr_rebind<std::allocator<int>, int>' required here
>> using rebind_alloc = typename __alloctr_rebind<_Alloc,
>> _Tp>::__type;
>> ^~~~~
>> ./linux-glibc/include/c++/4.7\ext/alloc_traits.h:183:47: note: in
>> instantiation of template type alias 'rebind_alloc'
>> requested here
>> { typedef typename _Base_type::template rebind_alloc<_Tp>
>> other; };
>> ^
>> ./linux-glibc/include/c++/4.7\bits/stl_vector.h:75:59: note: in
>> instantiation of template class
>> '__gnu_cxx::__alloc_traits<std::allocator<int>
>> >::rebind<int>' requested here
>> typedef typename __gnu_cxx::__alloc_traits<_Alloc>::template
>> ^
>> ./linux-glibc/include/c++/4.7\bits/stl_vector.h:208:30: note: in
>> instantiation of template class 'std::_Vector_base<int,
>>
>> std::allocator<int> >' requested here
>> class vector : protected _Vector_base<_Tp, _Alloc>
>> ^
>> foo.cpp:2:18: note: in instantiation of template class
>> 'std::vector<int, std::allocator<int> >' requested here
>> std::vector<int> foo;
>> ^
>
> foo.cpp is a really simple source file which looks like this:
>
> // foo.cpp
> #include <vector>
> std::vector<int> foo;
> // end
>
> The "linux-glibc/include" is a pretty large directory containing the
> entire /usr/include directory from my Linux machine.
>
> Compiling the same program on Linux works fine. I've compared the
> include file order, preprocessor symbols, and the list of options
> being passed to the compiler driver ('clang -v ... foo.cpp'), and I
> cannot find anything significant which is different. (Some things
> are naturally different; for example Clang on Windows is compiling
> 32-bit binaries, while my Linux-Clang is building 64-bit ones).
>
> Are there other internal differences between Clang when run on
> Windows vs. Linux which may account for this?
>
> --
> *Jesper Eskilson* /Development Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> E-mail: jesper.eskilson at iar.com <mailto:jesper.eskilson at iar.com>
> Website: www.iar.com
> <http://www.iar.com> Twitter: www.twitter.com/iarsystems
> <http://www.twitter.com/iarsystems>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
--
*Jesper Eskilson* /Development Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
E-mail: jesper.eskilson at iar.com <mailto:jesper.eskilson at iar.com>
Website: www.iar.com
<http://www.iar.com> Twitter: www.twitter.com/iarsystems
<http://www.twitter.com/iarsystems>
More information about the cfe-dev
mailing list