Libc++ Windows preliminary test results

2011/9/26 Ruben Van Boxem <vanboxem.ruben@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.
  • 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>/ 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 :slight_smile:

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.

test.zip (61.4 KB)

- <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

uchar.h is part of ICU (http://icu-project.org/).

- 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)

http://msdn.microsoft.com/en-us/library/ybk95axf(v=vs.71).aspx says
that _snwprintf is equivalent to the standard swprintf.

- clang chokes on decltype of vswprintf, thinking the
__attribute__((__dllimport__)) is the function name.

Strange... testcase?

-Eli