[cfe-dev] Libc++ Windows preliminary test results

[Ruben Van Boxem]

2011/9/26 Ruben Van Boxem <vanboxem.ruben at gmail.com>

> Hi everyone,
>
> I have finally gotten libc++ in a linkable/testable state for Windows
> (MinGW). This means testit can be run, and useful results are obtained.
>
> Currently I'm linking GCC's libcupc++ to provide the __cxa_* functions and
> therefore I have to link with -Wl,--allow-multiple-definition. Nonetheless,
> there are a lot of tests passing, so I guess this will do for now. If you
> can say which tests can be fixed easily or how, I can provide patches.
>
> ****************************************************
> Results for /home/Ruben/libc++/test:
> using clang version 3.0 ()
> Target: x86_64-w64-mingw32
> Thread model: posix
> with -std=c++0x -stdlib=libc++ -I/home/Ruben/libc++/include
> ----------------------------------------------------
> sections without tests   : 1
> sections with failures   : 192
> sections without failures: 871
>                        +   ----
> total number of sections : 1064
> ----------------------------------------------------
> number of tests failed   : 621
> number of tests passed   : 3703
>                        +   ----
> total number of tests    : 4324
> ****************************************************
> Summary: 16.77% of the tests fail. I think this is a pretty good baseline,
> as I only fixed the compile errors for the library itself, and provided
> naive alternatives to any missing functions.
> The most interesting and fixable results:
>  - locale_t objects are created using the UNIX locale names, Windows uses
> different names, resulting in failures across the board here. I believe
> these strings are implementation-defined anyways, so there should either be
> a global locale-name-defining header (which defines macros for all the
> locale names used) and use these macros in the tests themselves.
>  - stdint macros seem absent, this may be a Clang stdint.h problem, or a
> mingw-w64 stdint.h problem, or both. I'll check that in detail.
>  - <atomic> and exception_ptr stuff is broken, it unimplemented.
>  - wchar_t is assumed to be 4 bytes wide. This is an unportable assumption.
> This results in warnings when assigning wchar_t's, but also with L'\x40003'
> wchar_t's where the hex value is out of range.
>  - <uchar.h>/<cuchar> is assumed to be present, which it is not on Windows.
> It is, though, somewhere in Kyrgyzstan: http://en.wikipedia.org/wiki/Uchar
>  - swprintf prototype is not the same for Windows (I did redefine it in
> support/win32/support.h header, maybe an inline overload would be better)
>  - clang chokes on decltype of vswprintf, thinking the
> __attribute__((__dllimport__)) is the function name.
>  - failures in complex, may be platform-related as well.
>  - setenv is not available on Windows, putenv is (and seems adequate for
> the tests).
>  - lots of io related errors in numerics/rand. Will need to investigate
> where those come from... Probably Microsoft using a different string form
> than expected.
>  - aligned storage tests, probably due to sizeof(long) != 8.
>  - lots of passes (ie not only failures)! Yay for me! And for Howard, cause
> he's probably the main reason for most of the passes :)
>
> I attached the test log in case anyone is also interested in following up
> on anything. I'll run the test suite through a GCC-compiled libc++ too, just
> to make sure Clang isn't messing up all too much...
>

It seems GCC messes up more than Clang, at least for libc++. The only thing
I can spot skimming through the log is some type_traits failures and other
ugly template errors. Let's say I'll rely on Clang to guide me from error to
error. Log is attached.


> Ruben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110926/5d7734e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/zip
Size: 62923 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110926/5d7734e8/attachment.zip>