Stephan T. Lavavej writes:

If stuff is broken, either in the compiler or the libraries, please report it *now* through Microsoft Connect - especially if it's a regression.

Are these two failures expected? 1. Some specializations in the library for char16_t and char32_t seem to be still missing, causing the lexical_cast tests to fail: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f- win2012R2-64on64-boost-bin-v2-libs-lexical_cast-test- lexical_cast_integral_types_test-test-msvc-14-0-debug-link-static-threading- multi.html 2. Boost.Config's constexpr test fails because A's operator int() is not called at line 37: https://github.com/boostorg/config/blob/develop/test/boost_no_constexpr.ipp

[Niall Douglas]

The VS2015 CTP6 changelog shows no bugs fixed in the compiler (https://support.microsoft.com/kb/2967191)? This is quite surprising. There are a number of compiler bugs yet, though it's night and day compared to VS2013.

Compiler fixes are being continuously checked in, but the people who write the changelogs don't always remember to ask the compiler devs for a list. Nor did they ask me for a list of STL fixes. I keep track of all STL fixes that are checked in, so I can write VCBlog posts about them (as I did for CTP1 [1], and will do again for RTM). But I don't immediately know what got into CTP6 - I'd need to ask somebody to verify what branch it was built from, or install it in a VM. I also keep track of STL features and compiler features (again for VCBlog posts) but not compiler fixes - there are just too many fixes and I can't accurately describe most of them. Approximately 80 STL bugs in our internal database (including Connect) have been fixed after CTP1. Notably, I overhauled <functional> to fix all known bugs, with the only limitation being Expression SFINAE. If the CTP6 branch is $/devdiv/Rel/D14Rel as the version number would seem to indicate, then it appears to contain both the overhaul and my later implementation of C++17 std::invoke(). This also means it contains fixes for several compiler bugs that I encountered along the way, including the interaction of PMDs with rvalues, and partial ordering among variadic templates. STL [1] http://blogs.msdn.com/b/vcblog/archive/2014/06/06/c-14-stl-features-fixes-an...

[Marcel Raad]

Are these two failures expected?

1. Some specializations in the library for char16_t and char32_t seem to be still missing, causing the lexical_cast tests to fail:

This is tracked by an active bug. I don't know if we'll have time to fix it for RTM.

2. Boost.Config's constexpr test fails because A's operator int() is not called at line 37: https://github.com/boostorg/config/blob/develop/test/boost_no_constexpr.ipp

Please file a bug for this one.

There are new ICEs in the Config, Move, and SmartPtr tests. I have reported them on MS Connect:

Thank you very much - I will bring these to the attention of the compiler devs immediately. STL

[Marcel Raad]

https://connect.microsoft.com/VisualStudio/feedback/details/1147196

I've brought this to the attention of the compiler dev working on constexpr. The Boost.Config ICE has vanished in our current development build, so it appears to have been fixed - they will resolve that bug. The other ICE still repros and has been assigned to the right dev. Thanks, STL

Ben Pope writes:

Perhaps you'll find this useful:

Thanks!

New failing tests (19) utility:string_ref_test2:msvc-14.0

Also reported on MS Connect now: https://connect.microsoft.com/VisualStudio/feedback/details/1150054

context:test_context:msvc-14.0 coroutine:test_symmetric_coroutine:msvc-14.0 coroutine:test_asymmetric_coroutine:msvc-14.0 coroutine2:test_coroutine:msvc-14.0

These seem to be fixed in the online compiler at http://webcompiler.cloudapp.net/.

tr1:std_test_mem_fn_tricky:msvc-14.0 tr1:test_mem_fn_tricky:msvc-14.0 tr1:std_test_ref_wrapper_tricky:msvc-14.0 tr1:test_ref_wrapper_tricky:msvc-14.0

These failing tests testing for std::unary_function and std::binary_function as base classes of std::reference_wrapper and std::mem_fn might be due to N4190 (removing deprecated <functional> stuff) and should probably be removed?

type_traits:has_nothrow_copy_test:msvc-14.0 type_traits:has_nothrow_assign_test:msvc-14.0 multiprecision:test_nothrow_cpp_rational:msvc-14.0 optional:optional_test_noexcept_move:msvc-14.0 function_types:interface_example:msvc-14.0 multi_index:test_key_extractors:msvc-14.0

No idea about these.

Joaquin M Lopez Munoz writes:

Maybe someone can try with version 19.00.22609, which is what teeks99-08f-win2012R2-64on64 is running? If it fails, then we have a compiler bug fixed on mainline.

Indeed, it fails with the same error messages as the regression test: error C2975: 'PtrToMember': invalid template argument for 'const_member_base', expected compile-time constant expression note: see declaration of 'PtrToMember' note: see reference to class template instantiation 'member' being compiled error C2975: 'PtrToMember': invalid template argument for 'non_const_member_base', expected compile time constant expression note: see declaration of 'PtrToMember'

Tom Kent writes:

On Thu, Feb 26, 2015 at 11:13 AM, Joaquin M Lopez Munoz wrote:

...

...

Ben Pope writes:

...

multi_index:test_key_extractors:msvc-14.0

This I strongly suspect is a compiler bug. I've tried reducing the problem to a simple test case but it works in webcompiler.cloudapp.net with version 19.00.22620:

[...]

I ran it on that same machine (with 19.00.22609) and it gave the following error.

Marcel Raad writes:

Indeed, it fails with the same error messages as the regression test:

Thanks Tom, Marcel Stephan, do you want me to file a ticket somewhere or is it OK given that the problem does not appear in 19.00.22620? Joaquín M López Muñoz Telefónica

Stephan T. Lavavej writes:

[Joaquin M Lopez Munoz]

...

Stephan, do you want me to file a ticket somewhere or is it OK given that the problem does not appear in 19.00.22620?

The webcompiler's builds are taken from the compiler front-end and library branch, so if it works there, this bug has already been fixed.

Unfortunately multi_index's test_key_extractors still ICEs in VC14 RTM, even though Joaquín's reduced version compiles fine now: boost\multi_index\member.hpp(65) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)

Stephan T. Lavavej-2 wrote

[Marcel Raad]

...

Unfortunately multi_index's test_key_extractors still ICEs in VC14 RTM, even though Joaquín's reduced version compiles fine now: boost\multi_index\member.hpp(65) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)

Can you provide a preprocessed file + command line? Doesn't have to be reduced.

I hope this is what you want (and I hope the attachment works when posting through Nabble's web interface), it was generated with c:\boost\libs\multi_index\test>cl /P /I"C:\boost" test_key_extractors.cpp Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 test_key_extractors.zip http://boost.2283326.n4.nabble.com/file/n4678307/test_key_extractors.zip -- View this message in context: http://boost.2283326.n4.nabble.com/Test-Runner-Update-to-vc14-0-CTP-6-tp4672... Sent from the Boost - Dev mailing list archive at Nabble.com.

[Marcel Raad]

I hope this is what you want

[STL]

Filed as DevDiv#1203543 "Boost.MultiIndex ICE, outdname.c 1036".

The compiler devs have determined that this is a duplicate of: https://connect.microsoft.com/VisualStudio/feedback/details/1577162/vc-inter... They've identified the problem. Thanks, STL

"Ben Pope" skrev i meddelandet news:mchkp2$q50$1@ger.gmane.org...

Perhaps you'll find this useful: ... New failing tests (19) ... New Passing tests (10) ... Send thanks to Marshall for the script.

I'd love more information about that script. I've been missing a way to tell if failures are new or years old. Regards, Niklas Angare