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

Ruben Van Boxem vanboxem.ruben at gmail.com
Mon Sep 26 08:56:22 PDT 2011


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. Compared to Mac OS X's ~2%
failures, it sucks, but well, libc++ wasn't written with Windows in mind :)
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...

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


More information about the cfe-dev mailing list