[boost] Clang 600 and BOOST_SYSTEM_CONSTEXPR causes error_code.hpp compile failure.
Paul A. Bristow via Boost
Windows 10 to build static libraries.
It comes to grief with these messages (the berbose gory details can be posted if anyone can help).
In file included from I:\modular-boost\boost/system/system_error.hpp:14:
I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer
template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
^~~~~~~~~~~~~~~~~~~~~~~~
I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here
template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT'
# define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This seems to be the ultimate cause
I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant
expression
BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc )
Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
I note this in error_code.hpp
#if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus >= 201700L
// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835
# undef BOOST_SYSTEM_HAS_CONSTEXPR
#endif
should this undef list also include clang, and if so which versions 600?
Or is there something about Boost.config and Codeblocks on Windows?
Adding unconditional # undef BOOST_SYSTEM_HAS_CONSTEXPR seems to work.
Suggestions welcome.
Paul
---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gavin Lambert via Boost
> Having failed to build Boost libraries using Clang 6.0.0 using
> b2/bjam on Windows, I am now trying instead to use Codeblocks on
> Windows 10 to build static libraries.
>
> It comes to grief with these messages (the berbose gory details can
> be posted if anyone can help).
>
> In file included from I:\modular-boost\boost/system/system_error.hpp:14:
> I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer
> template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
> ^~~~~~~~~~~~~~~~~~~~~~~~
> I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here
> template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT'
> # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]]
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This seems to be the ultimate cause
>
> I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant
> expression
> BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc )
>
> Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
to "constexpr" (according to the error you're getting) but is instead
expanding to "".
Normally the latter occurs in environments that don't support constexpr
while the former occurs in environments that do; conversely I'd assume
that BOOST_SYSTEM_REQUIRE_CONST_INIT would also be disabled in
environments that don't support constexpr.
So some of the defines appear to think that constexpr is supported while
others think that it is not. Perhaps you can focus on what conditions
drive each of these definitions?
I don't know what the actual resolution to this is, but perhaps it helps?
Marshall Clow via Boost
box, I don't know that.
* Clang defines __GNUC__ to 4 (for compatibility reasons), so this #ifdef
should never fire under clang.
* This block of code is to work around a bug in gcc that clang doesn't have.
-- Marshall
Peter Dimov via Boost
> Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on
> Windows, I am now trying instead to use Codeblocks on Windows 10 to build
> static libraries.
Clang 6 on Travis.
https://travis-ci.org/boostorg/system/jobs/398224285
> It comes to grief with these messages (the berbose gory details can be
> posted if anyone can help).
>
> In file included from I:\modular-boost\boost/system/system_error.hpp:14:
> I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does
> not have a constant initializer
> template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category
> cat_holder<T>::system_category_instance;
the way.
> I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr
> constructor 'error_category' cannot be used in a constant expression
> BOOST_SYSTEM_CONSTEXPR explicit std_category(
> boost::system::error_category const * pc ): pc_( pc )
doesn't make sense because otherwise line 409 won't be reached - or there's
something else going on and the complete error log might help.
> Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
> I note this in error_code.hpp
>
> #if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus
> >= 201700L
#if defined(__GNUC__) && (__GNUC__ == 7 && __GNUC_MINOR__ < 4) &&
__cplusplus >= 201700L
because the GCC bug has been fixed for 7.4 and 8.1.
> should this undef list also include clang, and if so which versions 600?
John Maddock via Boost
On 07/07/2018 18:14, Peter Dimov via Boost wrote:
> Paul A. Bristow wrote:
>> Having failed to build Boost libraries using Clang 6.0.0 using
>> b2/bjam on Windows, I am now trying instead to use Codeblocks on
>> Windows 10 to build static libraries.
>
> I'll need more information than that, because the tests for System
> pass on Clang 6 on Travis.
>
> https://travis-ci.org/boostorg/system/jobs/398224285
It's the windows build that's the issue, not Linux.
Compiling from within the VC IDE using the clang installed LLVM-2014
toolset, and the full command line options:
/GS /GL /W3 /Gy /Zc:wchar_t /I"m:\data\boost\boost" /Zi /Gm- /O2
/Fd"x64\Release\system.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_LIB"
/D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi
/MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\"
/Fp"x64\Release\system.pch"
I see:
1>clang-cl.exe : warning : argument unused during compilation: '/Gm-'
[-Wunused-command-line-argument]
1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:16:
1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): error :
constexpr constructor never produces a constant expression
[-Winvalid-constexpr]
1> BOOST_SYSTEM_CONSTEXPR explicit std_category(
boost::system::error_category const * pc ): pc_( pc )
1> ^
1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note:
non-constexpr constructor 'error_category' cannot be used in a constant
expression
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\system_error(168,18): note: declared here
1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
1> ^
1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19:
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(78,33): warning
: 'strerror' is deprecated: This function or variable may be unsafe.
Consider using strerror_s instead. To disable deprecation, use
_CRT_SECURE_NO_WARNINGS. See online help for details.
[-Wdeprecated-declarations]
1> const char * c_str = std::strerror( ev );
1> ^
1>C:\Program Files (x86)\Windows
Kits\10\Include\10.0.16299.0\ucrt\string.h(180,16): note: 'strerror'
has been explicitly marked deprecated here
1>_Check_return_ _CRT_INSECURE_DEPRECATE(strerror_s)
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\vcruntime.h(269,55): note: expanded from macro
'_CRT_INSECURE_DEPRECATE'
1> #define _CRT_INSECURE_DEPRECATE(_Replacement)
_CRT_DEPRECATE_TEXT( \
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\vcruntime.h(259,47): note: expanded from macro
'_CRT_DEPRECATE_TEXT'
1>#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
1> ^
1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19:
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,73): error
: variable does not have a constant initializer
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
system_error_category system_category_instance;
1> ^~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,1): note:
required by 'require_constant_initialization' attribute here
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
system_error_category system_category_instance;
1>^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/error_code.hpp(392,44): note:
expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT'
1># define BOOST_SYSTEM_REQUIRE_CONST_INIT
[[clang::require_constant_initialization]]
1> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note:
non-constexpr constructor 'error_category' cannot be used in a constant
expression
1> BOOST_SYSTEM_CONSTEXPR explicit std_category(
boost::system::error_category const * pc ): pc_( pc )
1> ^
1>m:\data\boost\boost\boost/system/error_code.hpp(252,70): note: in
call to 'std_category(&system_category_instance)'
1> BOOST_SYSTEM_CONSTEXPR error_category() BOOST_SYSTEM_NOEXCEPT:
std_cat_( this ) {}
1> ^
1>m:\data\boost\boost\boost/system/error_code.hpp(370,28): note: in
call to 'error_category()'
1> BOOST_SYSTEM_CONSTEXPR system_error_category() BOOST_SYSTEM_NOEXCEPT
1> ^
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,73): note:
in call to 'system_error_category()'
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
system_error_category system_category_instance;
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\system_error(168,18): note: declared here
1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
1> ^
1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19:
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,74): error
: variable does not have a constant initializer
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
generic_error_category generic_category_instance;
1> ^~~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,1): note:
required by 'require_constant_initialization' attribute here
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
generic_error_category generic_category_instance;
1>^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/error_code.hpp(392,44): note:
expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT'
1># define BOOST_SYSTEM_REQUIRE_CONST_INIT
[[clang::require_constant_initialization]]
1> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note:
non-constexpr constructor 'error_category' cannot be used in a constant
expression
1> BOOST_SYSTEM_CONSTEXPR explicit std_category(
boost::system::error_category const * pc ): pc_( pc )
1> ^
1>m:\data\boost\boost\boost/system/error_code.hpp(252,70): note: in
call to 'std_category(&generic_category_instance)'
1> BOOST_SYSTEM_CONSTEXPR error_category() BOOST_SYSTEM_NOEXCEPT:
std_cat_( this ) {}
1> ^
1>m:\data\boost\boost\boost/system/error_code.hpp(354,28): note: in
call to 'error_category()'
1> BOOST_SYSTEM_CONSTEXPR generic_error_category() BOOST_SYSTEM_NOEXCEPT
1> ^
1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,74): note:
in call to 'generic_error_category()'
1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL
generic_error_category generic_category_instance;
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\system_error(168,18): note: declared here
1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
1> ^
1>1 warning and 3 errors generated.
I believe the error is correct as well: class std_category has virtual
member functions and so no constructor can ever be constexpr as the type
can never be a literal.
HTH, John.
---
This email has been checked for viruses by AVG.
https://www.avg.com
Peter Dimov via Boost
> 1>C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\include\system_error(168,18): note: declared here
> 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
Now how do we work around it...
> I believe the error is correct as well: class std_category has virtual
> member functions and so no constructor can ever be constexpr as the type
> can never be a literal.
Peter Dimov via Boost
>
> > 1>C:\Program Files (x86)\Microsoft Visual Studio
> > 14.0\VC\include\system_error(168,18): note: declared here
> > 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
>
> This commented-out constexpr (in the 2015 headers) is the problem, thanks.
> Now how do we work around it...
depending on who knows what search algorithm, and to work around the
commented-out constexpr I need to detect that it uses the 2015 STL (because
the 2017 STL would presumably have the constexpr, although I haven't checked
all of its flavors.)
I'm not sure that checking _MSC_VER would be enough, as I suspect that Clang
doesn't take the compatibility version into account when searching for
headers to use. There's _CPPLIB_VER, but I can't find what values correspond
to what versions. Boost.Config says that certain things appeared in 520,
540, 610, 650, but what releases do these correspond to?
In addition, Microsoft stopped increasing _CPPLIB_VER at some point
(starting with 2017?), then added their own macro (a welcome addition) but I
can't recall how that was called, when it was added, and can find no info on
that either. :-)
It ain't easy.
degski via Boost
wrote:
> I'm not sure that checking _MSC_VER would be enough, as I suspect that
> Clang doesn't take the compatibility version into account when searching
> for headers to use.
>
In addition, Microsoft stopped increasing _CPPLIB_VER at some point
> (starting with 2017?), then added their own macro (a welcome addition) but
> I can't recall how that was called, when it was added, and can find no info
> on that either.
>
degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*
degski via Boost
> Clang doesn't take the compatibility version into account when searching
> for headers to use.
>
file(s), see attached.
John Maddock via Boost
On 08/07/2018 15:42, Peter Dimov via Boost wrote:
>> John Maddock wrote:
>>
>> > 1>C:\Program Files (x86)\Microsoft Visual Studio >
>> 14.0\VC\include\system_error(168,18): note: declared here
>> > 1> /* constexpr */ error_category() _NOEXCEPT //
>> TRANSITION
>>
>> This commented-out constexpr (in the 2015 headers) is the problem,
>> thanks. Now how do we work around it...
>
> The problem here is that Clang can pick up and use any MSVC headers it
> finds depending on who knows what search algorithm, and to work around
> the commented-out constexpr I need to detect that it uses the 2015 STL
> (because the 2017 STL would presumably have the constexpr, although I
> haven't checked all of its flavors.)
I preprocessed the source and it's picking up the latest headers for me:
m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error
and I still see:
class error_category
{ // categorize an error
public:
/* constexpr */ error_category() _NOEXCEPT // TRANSITION
{ // default constructor
_Addr = reinterpret_cast<uintptr_t>(this);
}
In that header.
Defines wise we have:
Clang version 6.0.0 (tags/RELEASE_600/final)
_CPPUNWIND =1
__cplusplus =201402L
_WIN32 =1
_WIN64 =1
_CPPRTTI =1
_CPPUNWIND =1
_DLL =1
_M_AMD64 =100
_M_X64 =100
_MSC_BUILD =1
_MSC_EXTENSIONS =1
_MSC_VER =1900
_MSC_FULL_VER =190000000
_MSVC_LANG =201402L
_MT =1
_NATIVE_WCHAR_T_DEFINED =1
__VERSION__ ="4.2.1 Compatible Clang
6.0.0 (tags/RELEASE_600/final)"
Dinkumware standard library version 650
_CPPLIB_VER =650
_GLOBAL_USING =1
_HAS_EXCEPTIONS =1
_HAS_CXX17 =0
_HAS_AUTO_PTR_ETC =1
_HAS_OLD_IOSTREAMS_MEMBERS =1
_HAS_FUNCTION_ASSIGN =1
_HAS_TR1_NAMESPACE =1
_HAS_IDENTITY_STRUCT =1
_ITERATOR_DEBUG_LEVEL =2
_HAS_ITERATOR_DEBUGGING =1
_ITERATOR_DEBUG_ARRAY_OVERLOADS =1
Not sure if this helps, John.
---
This email has been checked for viruses by AVG.
https://www.avg.com
degski via Boost
> https://github.com/boostorg/regex/issues/44 was a fix in regex.
>
and _MSC_VER are defined (it's odd, but unique). clang-cl defines "_MSC_VER=0"
iff -fmsc-version is not set.
Peter Dimov via Boost
> I preprocessed the source and it's picking up the latest headers for me:
> m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error
>
> and I still see:
>
> class error_category
> { // categorize an error
> public:
> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
I have 14.14.26428 and I see the same. :-/
Well this sure simplifies version checking for this particular issue if
nothing else.
> Defines wise we have:
...
> _CPPLIB_VER =650
After looking at the config_info output from the test matrix, the values
are, for reference:
_CPPLIB_VER=405: msvc-8.0
_CPPLIB_VER=505: msvc-9.0
_CPPLIB_VER=520: msvc-10.0
_CPPLIB_VER=540: msvc-11.0
_CPPLIB_VER=610: msvc-12.0
_CPPLIB_VER=650: msvc-14.0 and above
The new macros are:
"The STL now identifies itself with two macros, defined by including any STL
header (e.g. <ciso646>). _MSVC_STL_VERSION is defined as 141 and will remain
that way for the VS 2017 v141 toolset series. _MSVC_STL_UPDATE is defined as
201709 in VS 2017 15.5, and will be increased as features are added in
future updates. (The year-month typically won’t correspond to an update’s
release date. Our process for updating this macro is “we’re checking in
std::meow() and it’s now October, so we need to change the value”, and
depending on branch/merge timing, it might take a month or more to ship.)
The value for VS 2017 15.6 is not yet set in stone, but it will be 201711 or
greater."
https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-15-5-and-15-6/
and I was going to suggest we add them, but someone already did:
https://github.com/boostorg/config/commit/d5986d697ca534e18d192bd28b8c1177fe220157
Incidentally... while looking into this, I encountered
https://github.com/boostorg/config/commit/15a0c119a13938bd00b99273e6fb876ff019c688
which uses the compiler version to decide on a library feature. It will
define BOOST_NO_CXX17_STD_APPLY under Clang.
It might be a good idea to codify the above knowledge somehow into a
BOOST_MSSTL_VERSION macro and then check that instead of _MSC_VER or
BOOST_MSVC which generally doesn't work with Clang.
Peter Dimov via Boost
> Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on
> Windows, I am now trying instead to use Codeblocks on Windows 10 to build
> static libraries.
>
> It comes to grief with these messages (the berbose gory details can be
> posted if anyone can help).
James E. King III via Boost
wrote:
> John Maddock wrote:
It sounds like Boost.Predef could help here, since it can detect Dinkumware?
- Jim