[config] Changes needed for VC++ 2015 Update 3?
The VS 2015 Update 3 release candidate has been announced. See https://blogs.msdn.microsoft.com/vcblog/2016/06/07/compiler-improvements-in-... (The following is partially for Boost developers who care about msvc, and partially to remind myself of what may need to be done to support update 3. It will be several weeks before I can work on this, so if any of the other config maintainers want to step in, please do so.) Update 3 supports standards versioning switches similarly to gcc, clang, and other compilers. We probably want to update Boost.Config accordingly. See https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche... Update 3 fixes lots of constexpr bugs, so we need to review whether or not BOOST_NO_CXX11_CONSTEXPR is still required. Note that in develop there is an undocumented config macro BOOST_MSVC_CXX11_CONSTEXPR that turns off BOOST_NO_CXX11_CONSTEXPR to facilitate testing. Update 3 fixes the expression SFINAE issues that were causing most of the Boost develop test failures. https://blogs.msdn.microsoft.com/vcblog/2016/06/07/expression-sfinae-improve... Quoting from that: There are still three failing tests in the Boost [develop] test suite when compiling with MSVC. Two test failures relate to using the noexcept operator in a template type argument. We currently parse it immediately, even in a dependent context. One test failure is a Boost library issue that we’ve reported to the [library's] maintainers. There are still known update 3 expression SFINAE issues (see "What remains to be done?" in the blog article) so do we continue to define BOOST_NO_SFINAE_EXPR? There is an undocumented BOOST_MSVC_SFINAE_EXPR macro in develop that turns off BOOST_NO_SFINAE_EXPR, so it is easy for developers to use msvc expression SFINAE if the want to. But our usual criteria for a _NO_ macro is not full compliance, but whether or not Boost code works with a feature. So using that criteria for update 3 we would remove BOOST_NO_SFINAE_EXPR. Opinions? --Beman <aside> We always urged Microsoft to test their releases against Boost. For update 3 expression SFINAE, they did exactly that. Thanks to Microsoft's Andrew Pardoe for coordinated the effort and to Xiang Fan for running the tests and tracking down the reason for each test failure. An undocumented Boost.Config macro BOOST_MSVC_SFINAE_EXPR to support their testing. The approach was to run tests for all libraries with the normal test setup, and then run again with BOOST_MSVC_SFINAE_EXPR defined. If the problem was with the Boost library, Xiang then reported it to me. I need to review a long series of email exchanges with him to make sure I alerted library maintainers to any Boost problems. </aside>
Beman Dawes wrote
Update 3 fixes lots of constexpr bugs, so we need to review whether or not BOOST_NO_CXX11_CONSTEXPR is still required.
I'm still getting a lot of "warning C4592: symbol will be dynamically initialized (implementation limitation)". At least Boost.Thread seems to rely on BOOST_NO_CXX11_CONSTEXPR to detect if variables would be statically initialized. -- View this message in context: http://boost.2283326.n4.nabble.com/config-Changes-needed-for-VC-2015-Update-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Marcel Raad wrote:
Beman Dawes wrote
Update 3 fixes lots of constexpr bugs, so we need to review whether or not BOOST_NO_CXX11_CONSTEXPR is still required.
I'm still getting a lot of "warning C4592: symbol will be dynamically initialized (implementation limitation)". At least Boost.Thread seems to rely on BOOST_NO_CXX11_CONSTEXPR to detect if variables would be statically initialized.
We probably need a dedicated macro for this. It's a separate feature and disabling constexpr for all other libraries that could have made use of it would be overkill.
Peter Dimov <lists@pdimov.com> wrote:
Marcel Raad wrote:
Beman Dawes wrote
Update 3 fixes lots of constexpr bugs, so we need to review whether or not BOOST_NO_CXX11_CONSTEXPR is still required.
I'm still getting a lot of "warning C4592: symbol will be dynamically initialized (implementation limitation)". At least Boost.Thread seems to rely on BOOST_NO_CXX11_CONSTEXPR to detect if variables would be statically initialized.
We probably need a dedicated macro for this. It's a separate feature and disabling constexpr for all other libraries that could have made use of it would be overkill.
+1 --Beman
I'm still getting a lot of "warning C4592: symbol will be dynamically initialized (implementation limitation)". At least Boost.Thread seems to rely on BOOST_NO_CXX11_CONSTEXPR to detect if variables would be statically initialized.
We probably need a dedicated macro for this. It's a separate feature and disabling constexpr for all other libraries that could have made use of it would be overkill.
+1
If it's predominantly a single library issue, then a BOOST_WORKAROUND should do it? But yes we should definitely enable the new features. John.
John Maddock wrote:
If it's predominantly a single library issue, then a BOOST_WORKAROUND should do it? But yes we should definitely enable the new features.
We already have BOOST_CONSTEXPR_OR_CONST and BOOST_STATIC_CONSTEXPR which are supposed to be used in these cases (statically initializing variables) - as opposed to BOOST_CONSTEXPR which covers the other constexpr meaning (functions evaluated at compile time). Although things are probably made worse by the fact that MSVC does initialize statically literal types, just not non-literals with a user-defined constexpr constructor (if I'm not mistaken).
On Jun 8, 2016, at 1:33 PM, Peter Dimov <lists@pdimov.com> wrote:
John Maddock wrote:
If it's predominantly a single library issue, then a BOOST_WORKAROUND should do it? But yes we should definitely enable the new features.
We already have BOOST_CONSTEXPR_OR_CONST and BOOST_STATIC_CONSTEXPR which are supposed to be used in these cases (statically initializing variables) - as opposed to BOOST_CONSTEXPR which covers the other constexpr meaning (functions evaluated at compile time).
Although things are probably made worse by the fact that MSVC does initialize statically literal types, just not non-literals with a user-defined constexpr constructor (if I'm not mistaken).
If it has a constexpr constructor then it is a literal type unless it has a non-trivial destructor. However, I don’t think clang nor gcc will statically initialize a type with a non-trivial destructor either(even with a constexpr constructor).
Beman Dawes wrote:
Update 3 supports standards versioning switches similarly to gcc, clang, and other compilers. We probably want to update Boost.Config accordingly.
See https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche...
I'm not sure that this is a positive development. Does the compiler provide a way to detect the mode it's in?
On Wed, Jun 8, 2016 at 8:05 AM, Peter Dimov <lists@pdimov.com> wrote:
Beman Dawes wrote:
Update 3 supports standards versioning switches similarly to gcc, clang,
and other compilers. We probably want to update Boost.Config accordingly.
See
https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche...
I'm not sure that this is a positive development.
Does the compiler provide a way to detect the mode it's in?
I don't know, but there are already comments on their blog (including from me) asking for that. I ping them to make sure lack of that would be a showstopper for Boost to make use of this. --Beman
Andrew Pardoe asked me to post his reply:
<aside> We always urged Microsoft to test their releases against Boost. For update 3 expression SFINAE, they did exactly that. Thanks to Microsoft's Andrew Pardoe for coordinated the effort and to Xiang Fan for running the tests and tracking down the reason for each test failure. An undocumented Boost.Config macro BOOST_MSVC_SFINAE_EXPR to support their testing. The approach was to run tests for all libraries with the normal test setup, and then run again with BOOST_MSVC_SFINAE_EXPR defined. If the problem was with the Boost library, Xiang then reported it to me. I need to review a long series of email exchanges with him to make sure I alerted library maintainers to any Boost problems. </aside>
Thank you, Beman, for the kind words. As we work to make MSVC completely standards-conforming we’ve been focusing on the libraries that our developers (both inside and outside of Microsoft) want to use. Not surprisingly, Boost is on the top of that list. If any of the Boost maintainers need to coordinate with MSVC please don’t hesitate to reach out to me. We’ll continue to prioritize your issues so that we can get—and keep—Boost compiling on MSVC without special-casing conditional code.
participants (5)
-
Beman Dawes -
John Maddock -
Marcel Raad -
Paul Fultz II -
Peter Dimov