Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn’t use default a.out on Windows) could also run the tests. That patch could use some work, I’ll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format…).
The bad news: Making this document sucked, and I’m never doing it again.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I’ll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
I’ll be using this as a basis to further fix Windows issues, but I’ll have less time from now on. It is a nice baseline status of libc++ on Windows. Help is always appreciated 
Ruben
results.Windows (33.4 KB)
Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn't use default a.out on Windows) could also run the tests. That patch could use some work, I'll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format...).
The bad news: Making this document sucked, and I'm never doing it again.
Thanks for your work on this.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I'll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
There's a link off this page:
http://libcxx.llvm.org/
to:
http://libcxx.llvm.org/results.Windows.html
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
#include <iostream>
int main()
{
std::cout << __cplusplus << '\n';
}
Without -std=c++0x:
1
With -std=c++0x:
201103
Howard
Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn't use default a.out on Windows) could also run the tests. That patch could use some work, I'll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format...).
The bad news: Making this document sucked, and I'm never doing it again.
Thanks for your work on this.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I'll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
There's a link off this page:
http://libcxx.llvm.org/
to:
http://libcxx.llvm.org/results.Windows.html
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
#include <iostream>
int main()
{
std::cout << __cplusplus << '\n';
}
Without -std=c++0x:
1
With -std=c++98:
199711
(The definition of __cplusplus in the default gnu98 mode is is an old G++'ism Clang emulates)
2011/9/28 Howard Hinnant <hhinnant@apple.com>
Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn’t use default a.out on Windows) could also run the tests. That patch could use some work, I’ll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format…).
The bad news: Making this document sucked, and I’m never doing it again.
Thanks for your work on this.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I’ll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
There’s a link off this page:
http://libcxx.llvm.org/
to:
http://libcxx.llvm.org/results.Windows.html
Thanks for the free publicity 
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
#include
int main()
{
std::cout << __cplusplus << ‘\n’;
}
Without -std=c++0x:
1
With -std=c++0x:
201103
Doh! Could’ve done that myself. Good to know Clang does it right at least, even though the support is still incomplete.
Ruben
2011/9/28 Douglas Gregor <dgregor@apple.com>
Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn’t use default a.out on Windows) could also run the tests. That patch could use some work, I’ll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format…).
The bad news: Making this document sucked, and I’m never doing it again.
Thanks for your work on this.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I’ll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
There’s a link off this page:
http://libcxx.llvm.org/
to:
http://libcxx.llvm.org/results.Windows.html
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
#include
int main()
{
std::cout << __cplusplus << ‘\n’;
}
Without -std=c++0x:
1
With -std=c++98:
199711
(The definition of __cplusplus in the default gnu98 mode is is an old G++'ism Clang emulates)
It’s not an old G++'ism. it’s only recently been fixed and is only for GCC 4.7+: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
That’s kind of why I asked. This is very good news. Clang has just become even more awesome
Ruben
(The definition of __cplusplus in the default gnu98 mode is is an old
G++'ism Clang emulates)
Note that this has changed on the gcc trunk.
-miles
Ruben Van Boxem <vanboxem.ruben@gmail.com>
writes:
> std::cout << __cplusplus << '\n';
>
> Without -std=c++0x:
> 1
> With -std=c++0x:
> 201103
Doh! Could've done that myself. Good to know Clang does it right at least,
even though the support is still incomplete. <evil look at the GCC
>
Note that the issues behind __cplusplus being "1" in gcc finally seem
to have been resolved (my vague understanding is that it had something
to do with system include files in Solaris!). The gcc trunk now
always uses a value of 199711 for __cplusplus.
It'll be quite a while before the value of __cplusplus is a reliable
indicator of c++11 features being available though (as demonstrated by
clang's setting!), so code probably shouldn't be using it to test for
them [unless it's intimately related to a particular compiler
distribution, and so can make detailed assumptions about what the
value implies]...
-miles
NOOOOOOOO!!!
What is the rational for defining it before the C++11 support is (almost) complete? The main point of the value of this macro is imho to be able to detect whether we can use C++11 features. If you want to indicate experimental partial support, a compiler specific macro is fine. But defining __cplusplus to 201103 when the new standard isn't implemented yet makes the macro useless. The only rational I could think of is that the C++11 mode of clang is considered experimental and unsupported and thus it doesn't matter that it doesn't work...
As a (header) library writer who wants to use C++11 features if possible, my choices are __cplusplus or version tests on all the compilers I can get my hands on. You can guess which one I prefer.
I'm sure there was a good reason for setting the new value and I'd like to hear it... (this discussion probably should have taken place on the reflectors to get the vendors to agree on a strategy)
2011/9/28 Marc Glisse <marc.glisse@inria.fr>
#include
int main()
{
std::cout << __cplusplus << ‘\n’;
}
Without -std=c++0x:
1
With -std=c++0x:
201103
NOOOOOOOO!!!
What is the rational for defining it before the C++11 support is (almost) complete? The main point of the value of this macro is imho to be able to detect whether we can use C++11 features. If you want to indicate experimental partial support, a compiler specific macro is fine. But defining __cplusplus to 201103 when the new standard isn’t implemented yet makes the macro useless. The only rational I could think of is that the C++11 mode of clang is considered experimental and unsupported and thus it doesn’t matter that it doesn’t work…
As a (header) library writer who wants to use C++11 features if possible, my choices are __cplusplus or version tests on all the compilers I can get my hands on. You can guess which one I prefer.
I’m sure there was a good reason for setting the new value and I’d like to hear it… (this discussion probably should have taken place on the reflectors to get the vendors to agree on a strategy)
Clang has the __has_feature macros to detect if anything is present or missing, exactly for this purpose. Libc++ is as far as I know feature complete, only missing support, which is in active development.
The reason I like that the macro is defined, is that things like the uchar.h header can use it to see if char16_t/char32_t are builting types, or if it is safe/better to typedef them. This is impossible with GCC, which made the required ifdef… very lengthy.
Ruben
Other system headers also use this macro to expose C99 functions in C++ mode. If you're compiling in C++98 mode, C99 stuff is all hidden. If you're compiling in C++11 mode, it should be visible. This doesn't depend on any features of the compiler beyond C99 support, but it does depend on the language dialect that the programmer selected.
David
Well, given that the C++03 support isn't finished, and probably never will be, we should probably remove the c++98 definition too
In practice the C++0x support is in a good state, I know a number of people (including myself) who are using it on a day-to-day basis, and I suspect it will be years, if ever, before the compiler is 100% standards compliant.
Chris
… and other compilers that don't have complete C++11 support (= all of them) are also defining __cplusplus to 201103, so you can't actually depend on 201103 to mean "everything in C++11" in portable code anyway.
- Doug
2011/9/28 Ruben Van Boxem <vanboxem.ruben@gmail.com>
Hi,
Attached is a file describing in detail what libc++ tests failed in my test run and why (if it could be easily deduced from comparing Clang/GCC output or from the helpful Clang error messages). I used a slightly modified testit, so that GCC (which doesn’t use default a.out on Windows) could also run the tests. That patch could use some work, I’ll keep it local for now.
The good news: a lot of these have trivial fixes, and the fault lies in the tests themselves (size of wchar_t, locale names, different number output format…).
The bad news: Making this document sucked, and I’m never doing it again.
If in any way possible, thid could have a place in the libc++ source tree. It would make finding outstanding test failures and their reasons easy. Perhaps other platforms could then also keep track of failures. If not, I’ll create a general bug report for libc++ and attach this document. I of course plan to keep this updated once fixes are applied.
A small summarizing note:
- thread needs attention, probably most failures are due to winpthreads.
- io (actually most kinds of streams) needs attention, failures pops up everywhere.
- lots of regex failures. Not good.
- numerics has trouble with math functions. Perhaps a format issue.
- stdint.h and uchar.h issues are being dealt with.
Re the last point: How does Clang handle __cplusplus and C++11?
I’ll be using this as a basis to further fix Windows issues, but I’ll have less time from now on. It is a nice baseline status of libc++ on Windows. Help is always appreciated
The small work I’ve done on locale related stuff reduced failed test count from 621 to 438. Wow. Progress: almost under 10% I have attached an updated “results.Windows” to celebrate, and also the patch I used to run testit. The TEST_EXE is necessary for GCC compatibility, it does not use the default a.out, but a.exe instead. I still needed to use a static libc++ for this run… -Wl,–export-all-symbols seems insufficient for the dll to work (although nm does show the missing symbols, maybe a clang vs ld problem).
results.Windows (24.8 KB)
testit.patch (1.21 KB)
Committed revision 140950.
Thanks,
Howard