Compiling with clang or clang-cl on windows is not handled properly. See for example:
#if BOOST_CAPY_WORKAROUND(_MSC_VER, >= 1)
inline void symmetric_transfer(std::coroutine_handle<> h) noexcept
{
// safe_resume is not needed here: the calling coroutine is
// about to suspend unconditionally. When it later resumes,
// await_resume restores TLS from the promise's environment.
h.resume();
}
#else
inline std::coroutine_handle<>
symmetric_transfer(std::coroutine_handle<> h) noexcept
{
return h;
}
#endifBOOST_CAPY_WORKAROUND will evaluate to true here, so the less performant option is selected, even though the second one compiles and passes tests. Since this is an msvc codegen bug it shouldn't affect clang. This is the only place where I found where it will have a performance penalty.
Other projects often handle this with something like macros name FOO_COMPILER_CLANG, FOO_COMPILER_GCC and FOO_COMPILER_MSVC. If you want to check against specific versions of them then you can define them to the appropriate version string. Also a macro to recognize the OS is common instead of checking for _MSC_VER.
All the warning suppressing pragmas are ignored by clang-cl so these should also only be used on msvc.
In cmake also this is incorrect:
# Disable IPO/LTCG - causes LNK2016 errors with MSVC
set_target_properties(boost_capy PROPERTIES
EXPORT_NAME capy
INTERPROCEDURAL_OPTIMIZATION OFF
INTERPROCEDURAL_OPTIMIZATION_RELEASE OFF
INTERPROCEDURAL_OPTIMIZATION_RELWITHDEBINFO OFF
INTERPROCEDURAL_OPTIMIZATION_MINSIZEREL OFF)Unless I'm missing a place where this is reenabled for other systems, this should only be enabled for msvc (keeping in mind MSVC is also defined for clang-cl in cmake).
I assume it will be the same in corosio and the other connected.
Compiling with clang or clang-cl on windows is not handled properly. See for example:
BOOST_CAPY_WORKAROUND will evaluate to true here, so the less performant option is selected, even though the second one compiles and passes tests. Since this is an msvc codegen bug it shouldn't affect clang. This is the only place where I found where it will have a performance penalty.
Other projects often handle this with something like macros name FOO_COMPILER_CLANG, FOO_COMPILER_GCC and FOO_COMPILER_MSVC. If you want to check against specific versions of them then you can define them to the appropriate version string. Also a macro to recognize the OS is common instead of checking for _MSC_VER.
All the warning suppressing pragmas are ignored by clang-cl so these should also only be used on msvc.
In cmake also this is incorrect:
Unless I'm missing a place where this is reenabled for other systems, this should only be enabled for msvc (keeping in mind MSVC is also defined for clang-cl in cmake).
I assume it will be the same in corosio and the other connected.