Circle compiles the MULTI library (almost) #118
Comments
|
Thanks for the report. I'll get to work on it this week. |
|
The library is added to godbolt Circle now. https://godbolt.org/z/fMxE5GhYr |
|
This code block used to crash with circle 170.
#if defined(__cpp_deduction_guides) and not defined(__NVCC__) and not defined(__circle_build__) // circle 170 crashes
{
multi::array arr(multi::extensions_t<1>{{0, 10}}, double{});
BOOST_REQUIRE( size(arr)==10 );
BOOST_REQUIRE( arr[5]== double{} );
}
{
multi::array arr({{0, 10}}, double{});
BOOST_REQUIRE( size(arr)==10 );
BOOST_REQUIRE( arr[5]== double{} );
}
{
multi::array arr({10}, double{});
BOOST_REQUIRE( size(arr)==10 );
BOOST_REQUIRE( arr[5]== double{} );
}
{
multi::array arr(10, double{});
BOOST_REQUIRE( size(arr)==10 );
BOOST_REQUIRE( arr[5]== double{} );
}
#endif |
|
circle 198 now correctly recognizes these as a #if defined(__circle_build__) // circle doesn't see dimensionality as a constexpr "cannot access value of A at compile time;"
assert(multi::dimensionality(arr) == 3);
#else // other compilers ok
static_assert(multi::dimensionality(arr) == 3);
#endif#if defined(__circle_build__) // circle doesn't recognize this as a constexpr "cannot access value of `arr` at compile time;"
assert(multi::stride(arr) == 20);
#else // other compilers ok
static_assert(multi::stride(arr) == 20);
#endif |
|
Almost all problems have been solved at some point before version 198. Good job with the circle compiler! The only remaining issues are regarding This is a summary of the remaining cases that I was able to detect with my own library tests. {
#if not defined(__circle_build__) // crashes circle 198
multi::static_array const arr = {1.2, 3.4, 5.6};
BOOST_REQUIRE( size(arr) == 3 );
BOOST_REQUIRE( arr[2] == 5.6 );
BOOST_REQUIRE(( arr == multi::static_array{1.2, 3.4, 5.6} ));
#else
// multi::static_array const arr = {1.2, 3.4, 5.6};
#endif
}
{
#if not defined(__circle_build__)
multi::static_array arr({1.0, 2.0, 3.0});
static_assert(std::is_same<decltype(arr)::element_type, double>{}, "!");
BOOST_REQUIRE( size(arr) == 3 and num_elements(arr) == 3 );
BOOST_REQUIRE( multi::rank<decltype(arr)>{}==1 and num_elements(arr)==3 and arr[1] == 2.0 );
static_assert(typename decltype(arr)::rank{} == 1);
#else
// multi::static_array arr( {1.0, 2.0, 3.0}); // crashes circle
// multi::static_array arr(std::initializer_list<double>{1.0, 2.0, 3.0}); // crashes circle
#endif
}
{
#if not defined(__circle_build__)
multi::static_array const arr({
{1.0, 2.0, 3.0},
{4.0, 5.0, 6.0},
});
BOOST_TEST_REQUIRE( multi::rank<decltype(arr)>{} == 2 );
BOOST_TEST_REQUIRE( num_elements(arr) == 6 );
#else
// // vvv--- gives segfault in circle
// multi::static_array const arr({
// {1.0, 2.0, 3.0},
// {4.0, 5.0, 6.0},
// });
#endif
}
{
#if not defined(__circle_build__)
multi::array const arr({
{1.0, 2.0, 3.0},
{4.0, 5.0, 6.0},
});
BOOST_TEST_REQUIRE( multi::rank<decltype(arr)>{} == 2 );
BOOST_TEST_REQUIRE( num_elements(arr) == 6 );
#else
// // vvv--- gives error in circle, not viable constructor
// multi::array const arr({
// {1.0, 2.0, 3.0},
// {4.0, 5.0, 6.0},
// });
// vvv--- gives ODR violation in circle
// multi::array const arr(std::initializer_list<std::initializer_list<double>>{
// {1.0, 2.0, 3.0},
// {4.0, 5.0, 6.0},
// });
// vvv--- gives ODR violation in circle
// multi::array const arr(std::initializer_list<std::initializer_list<double>>{
// std::initializer_list<double>{1.0, 2.0, 3.0},
// std::initializer_list<double>{4.0, 5.0, 6.0},
// });
#endif
} |
|
Interestingly circle (v200) doesn't crash in godbolt and gives a meaningful error message: https://godbolt.org/z/desaP6noa The error is related to a constructor that shouldn't be invoked anyway, so it is SFINAE failing to fail. I have figured out a workaround in my local computer, but it is still segfaults in a docker image. The work around is to split the enable_if conditions into two enable_ifs, transform this code: template<class Element, std::enable_if_t<std::is_convertible_v<Element, typename static_array::element> && (D == 0), int> = 0>
explicit static_array(Element const& elem, allocator_type const& alloc)
: static_array(typename static_array::extensions_type{}, elem, alloc) {}into this code template<class Element,
std::enable_if_t<(D == 0) && sizeof(Element*), int> =0, // separate reqs for circle
std::enable_if_t<std::is_convertible_v<Element, typename static_array::element>, int> =0
>
explicit static_array(Element const& elem, allocator_type const& alloc)
: static_array(typename static_array::extensions_type{}, elem, alloc) {}but again, it still segfaults in some conditions. |
|
The problems with I found a new problem though regarding conversion operations, https://gitlab.com/correaa/boost-multi/-/jobs/6964145332#L714 I didn't find this problem in earlier versions (or with any other compiler https://gitlab.com/correaa/boost-multi/-/pipelines/1309447406), so I think it is a new problem. |
|
It looks like Circle never compiled that line.
Can you help me understand the conversion path from multi::array<T, 2> to
vector<vector<T>>? It requires a static_cast and not just a normal implicit
conversion, so it is using an explicit operator or explicit constructor or
something?
…On Tue, May 28, 2024 at 8:21 PM Alfredo Correa ***@***.***> wrote:
The problems with initializer_list are solved now in version 201.
I found a new problem though regarding conversion operations,
https://gitlab.com/correaa/boost-multi/-/jobs/6964145332#L714
I didn't find this problem in earlier versions (or with any other compiler
https://gitlab.com/correaa/boost-multi/-/pipelines/1309447406), so I
think it is a new problem.
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKJV222VTTOUHC4OVFDZEUNPLAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGYZTANJRHE4Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
You are right, it never compiled it.
I think it should be using a conversion operator of the RHS (multi::array), inherited from a base class (multi::subarray). |
|
Ok fixed i'll get it out tomorrow.
…On Tue, May 28, 2024 at 10:01 PM Alfredo Correa ***@***.***> wrote:
You are right, it never compiled it.
Sorry for my confusion.
static_cast shouldn't be necessary, normal implicit conversion should
work.
When implicit conversion didn't work for circle I changed it to a
static_castwhich didn't work either.
(whether an implicit conversion is a good idea in the first place is a
separate question, I think I made it implicit so it can work recursively
out-of-the-box, so any D-dimensional array could be converted to any
D-nested std::vector<std::vector<...>>, probably an overkill)
I think it should be using a conversion operator of the RHS
(multi::array), inherited from a base class (multi::subarray).
https://gitlab.com/correaa/boost-multi/-/blob/master/include/boost/multi/array_ref.hpp?ref_type=heads#L1516
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKJNGCXQO3HQQLOMCB3ZEUZHDAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGYZTQMRXGQ2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Cool. I now realize that expressions like I am testing it now, perhaps that works around the problem too. (I don't have a Linux to try with circle right now). Thanks, |
|
100% tests passed, 0 tests failed out of 53
Unfortunately, that conversion function template hiding fix broke some
libc++ tests. The wording is very poor about this:
"A conversion function template with a dependent return type hides only
templates in base classes that correspond to it"
https://eel.is/c++draft/class.conv#fct-6
What does "correspond to" mean? 🤔
…On Tue, May 28, 2024 at 11:03 PM Alfredo Correa ***@***.***> wrote:
Cool.
I now realize that expressions like A.operator
std::vector<std::vector<double>>() do not work when the template
conversion operator is inherited from the base class in many compilers (GCC
and clang), so I have to define the conversion in the leaf class as well
although it is a repetition of the base class.
I am testing it now, perhaps that works around the problem too. (I don't
have a Linux to try with circle right now).
Thanks,
A
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKOMUZLDLWAMAFC6YALZEVAQ3AVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGY2DGMBWGE2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Can you try https://www.circle-lang.org/linux/build_202.tgz ?
On my end this passes and builds all tests, except for the two statements
that rely on that conversion function we've been talking about. I'm trying
to get some wording help from CWG on it.
…On Wed, May 29, 2024 at 9:29 AM Sean ***@***.***> wrote:
100% tests passed, 0 tests failed out of 53
Unfortunately, that conversion function template hiding fix broke some
libc++ tests. The wording is very poor about this:
"A conversion function template with a dependent return type hides only
templates in base classes that correspond to it"
https://eel.is/c++draft/class.conv#fct-6
What does "correspond to" mean? 🤔
On Tue, May 28, 2024 at 11:03 PM Alfredo Correa ***@***.***>
wrote:
> Cool.
>
> I now realize that expressions like A.operator
> std::vector<std::vector<double>>() do not work when the template
> conversion operator is inherited from the base class in many compilers (GCC
> and clang), so I have to define the conversion in the leaf class as well
> although it is a repetition of the base class.
>
> I am testing it now, perhaps that works around the problem too. (I don't
> have a Linux to try with circle right now).
>
> Thanks,
> A
>
> —
> Reply to this email directly, view it on GitHub
> <#118 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAD7KKOMUZLDLWAMAFC6YALZEVAQ3AVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGY2DGMBWGE2Q>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
ok. i will try. i am getting a segfault with 201. https://gitlab.com/correaa/boost-multi/-/jobs/6971672356#L502 (see at the end) |
|
I fixed the cause of that segfault. I was trying to feed WCHAR_MIN to
std::isprint to test if it was printable, and that was segfaulting. It's UB
to feed it anything larger than 255. 😵💫
…On Wed, May 29, 2024 at 12:32 PM Alfredo Correa ***@***.***> wrote:
ok. i will try.
i am getting a segfault with 201.
actually, it happens often that circle crashes in docker but finishes
(with an error) in the real machine.
https://gitlab.com/correaa/boost-multi/-/jobs/6971672356#L502 (see at the
end)
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKIPYA2CMPYNSU6XJ5LZEX7IXAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTG44DENBYGY4Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I am getting this error with v202. Maybe it is a problem with my code: https://gitlab.com/correaa/boost-multi/-/jobs/6972753629#L1065 It is possible that I am truly making ODR violations and circle is the only compiler to detect those. |
|
I donno what the issue is. Here's the invocation on my machine with the
binary I just sent. It builds. Did you clean and re-run cmake? `circle
--version` shows build 202? My command line is showing a DTBB_FOUND=1
macro, but I doubt that is relevant.
cd /home/sean/projects/boost-multi/build2/test && /usr/bin/circle
-DBOOST_ALL_NO_LIB -DBOOST_NO_CXX98_FUNCTION_BASE=1 -DBOOST_TEST_DYN_LINK=1
-DBOOST_TEST_MODULE="\"C++ Unit Tests for Multi member_array_cast.cpp.x\""
-DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DTBB_FOUND=1
-I/home/sean/projects/boost-multi/include -MD -MT
test/CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o -MF
CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o.d -o
CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o -c
/home/sean/projects/boost-multi/test/member_array_cast.cpp
[ 52%] Linking CXX executable member_array_cast.cpp.x
…On Wed, May 29, 2024 at 1:31 PM Alfredo Correa ***@***.***> wrote:
I am getting this error now. Maybe it is a problem with my code:
https://gitlab.com/correaa/boost-multi/-/jobs/6972753629#L1065
cd /builds/correaa/boost-multi/build/test && /builds/correaa/boost-multi/build_latest/circle -DBOOST_ALL_NO_LIB -DBOOST_NO_CXX98_FUNCTION_BASE=1 -DBOOST_TEST_DYN_LINK=1 -DBOOST_TEST_MODULE="\"C++ Unit Tests for Multi member_array_cast.cpp.x\"" -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -I/builds/correaa/boost-multi/include -g -Werror -Wall -MD -MT test/CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o -MF CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o.d -o CMakeFiles/member_array_cast.cpp.x.dir/member_array_cast.cpp.o -c /builds/correaa/boost-multi/test/member_array_cast.cpp
ODR used by: element_transformed_from_member_invoker
/builds/correaa/boost-multi/test/member_array_cast.cpp:172:1
BOOST_AUTO_TEST_CASE(element_transformed_from_member) {
^
ODR used by: element_transformed_from_member::test_method
/builds/correaa/boost-multi/test/member_array_cast.cpp:184:54
multi::array<int, 2> ids = recs.element_transformed(&record::id);
^
ODR used by: boost::multi::array<int, 2l, std::allocator<int>>::array
/builds/correaa/boost-multi/include/boost/multi/array.hpp:352:25
/*mplct*/ static_array(multi::subarray<TT, D, Args...>&& other) // NOLINT(google-explicit-constructor,hicpp-explicit-conversions)
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKJH574UCZUMJT7F4WLZEYGHNAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTG44TENZVHA2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Yes, it is v202, in docker: https://gitlab.com/correaa/boost-multi/-/jobs/6972882032#L501 I am going to try in a real machine now. Maybe it is related to the fact that cmake is finding Clang as the compiler, which I didn't expect. |
|
https://www.circle-lang.org/linux/build_203.tgz
I got wording clarification on the conversion function hiding issue and
included the fix. Now boost-multi builds 100%.
FYI my system boost is 1.71 and yours is 1.74. Could the problems on your
end be traced to that? Can you point your system to boost 1.71?
Ok back to memory safety now.
…On Wed, May 29, 2024 at 2:15 PM Alfredo Correa ***@***.***> wrote:
Yes, it is v202, in docker:
https://gitlab.com/correaa/boost-multi/-/jobs/6972882032#L501
I am going to try in a real machine now. Maybe it is related to the fact
that cmake is finding Clang as the compiler, which I didn't expect.
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKKCLA3PWDGULFJWBWLZEYLKTAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTG44TSOJUHEZA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I get the ODR problem with v203 also, in a local machine Ubuntu 23.10. I am going to try a different version of Boost.Test or some docker image |
|
I reproduced the ODR error in docker, with Ubuntu 20.04, Boost.Test 1.71 https://gitlab.com/correaa/boost-multi/-/jobs/6974545208#L659 |
|
Argh! I should have paid more attention to your line numbers. In the
version of multi I pulled, this was at member_array_cast.cpp:
#if ! defined(__circle_build__)
That test was never getting built. I removed the #if and now I see that
error.
Apologies.
…On Wed, May 29, 2024 at 6:06 PM Alfredo Correa ***@***.***> wrote:
I reproduced the ODR error in docker, with Ubuntu 20.04, Boost.Test 1.71
https://gitlab.com/correaa/boost-multi/-/jobs/6974545208#L659
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKIZWUDZPPEEKIAENTDZEZGMVAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHAZTGNRZHEZQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Actually, I am sorry for the confusion with the Also, to bother you, memory safety is probably more important. Are you incorporating memory safety into Circle? In C++, I like the approach of LLVM/clang that tries to give memory safety through the standard library (e.g. span) and a bunch of really harsh warnings such as Wunsafe-buffer-usage that I am using myself to remind me that at some point I have to stop using pointer arithmetic and use |
|
I'm doing rigorous memory safety by implementing Rust's safety model
https://youtu.be/5Q1awoAwBgQ?si=AfbXk7Zg35Q1oyQk
…On Wed, May 29, 2024, 9:18 PM Alfredo Correa ***@***.***> wrote:
Actually, I am sorry for the confusion with the #ifdef.
Also, to bother you, memory safety is probably more important.
Are you incorporating memory safety into Circle? In C++, I like the
approach of LLVM/clang that tries to give memory safety through the
standard library (e.g. span) and a bunch of really harsh warnings such as
Wunsafe-buffer-usage that I am using myself to remind me that at some point
I have to stop using pointer arithmetic and use std::span instead (which
*can* be range checked).
https://gitlab.com/correaa/boost-multi/-/blob/master/include/boost/multi/array_ref.hpp?ref_type=heads#L643-669
—
Reply to this email directly, view it on GitHub
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7KKLCGJTZ5YKLXIEHZPDZEZ44XAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHA2DSOBYHEZA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I have been investigating this error and am really not sure what's going
on. The error message circle dumps out is pretty informative. The problem
is no viable candidate of the _ overload that's called from here:
adl.hpp:338:
template<class... As> constexpr auto operator()(As&&... args) const
BOOST_MULTI_DECLRETURN(_(priority<6>{}, std::forward<As>(args)...))
The candidates are the _ member functions with priority<1> through
priority<6>. The difficulty I'm having is that the _ function is called
from the decltype in the trailing-return-type, so it's an unevaluated
context and there's no code generated that I can step through in the
debugger or view through its LLVM IR.
Is there some cut down example that can be made for this failed
initialization? The problem is initializing ids from the result object of
recs.element_transformed into multi::array<int, 2>.
…On Wed, May 29, 2024 at 10:50 PM Sean ***@***.***> wrote:
I'm doing rigorous memory safety by implementing Rust's safety model
https://youtu.be/5Q1awoAwBgQ?si=AfbXk7Zg35Q1oyQk
On Wed, May 29, 2024, 9:18 PM Alfredo Correa ***@***.***>
wrote:
> Actually, I am sorry for the confusion with the #ifdef.
>
> Also, to bother you, memory safety is probably more important.
>
> Are you incorporating memory safety into Circle? In C++, I like the
> approach of LLVM/clang that tries to give memory safety through the
> standard library (e.g. span) and a bunch of really harsh warnings such as
> Wunsafe-buffer-usage that I am using myself to remind me that at some point
> I have to stop using pointer arithmetic and use std::span instead (which
> *can* be range checked).
> https://gitlab.com/correaa/boost-multi/-/blob/master/include/boost/multi/array_ref.hpp?ref_type=heads#L643-669
>
> —
> Reply to this email directly, view it on GitHub
> <#118 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAD7KKLCGJTZ5YKLXIEHZPDZEZ44XAVCNFSM5VD6YZB2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHA2DSOBYHEZA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
I see, so the problem is using decltype (expansion of DECLRETURN). For context, decltype is used both to reduce the amount of typing, but also to discard bad candidates for the operation. It is likely that the intention here is that the last candidate ( I will deconstruct the operation into more basic functions. Also, I am going to put this in terms of assignment and not initialization of a |
|
Okay, I think the problem is that Circle was the only compiler reaching the end of the priority list for adl_uninitialized_copy. This, in turn, is invalid code, and since it is an I am not saying Circle got anything wrong, perhaps it is the only one that got the priority right. template<class TB, class... As > constexpr auto _(priority<3>/**/, TB first, As&&... args ) const BOOST_MULTI_DECLRETURN( uninitialized_copy( first , std::forward<As>(args)...))If I am not mistaken this is because compilers tend to look at ADL in internal template parameters which I think it is a terrible rule and perhaps Circle for whatever (good or bad) reason was not doing it. I implemented the constructor differently so that I am testing this code for all the other compilers to ensure it works. For reference, the changes are in the |
|
Okay, I think it all works now. The library compiles with Circle from v202, v203, and v204. In the end, the problem was solved by implementing a better-quality constructor that (uninitialized_)copies elements. I don't know if the end circle is behaving differently than most (all?) other compilers. In any case, I am glad that this behavior of the circle forced me to improve the implementation. |
|
By the way, I'd be interested to know if you have any ideas (I don't) on how the memory-safe that you are building into Circle could be exploited by this array library. I guess the idea could be that subblocks of a bigger array can be passed (borrowed) to different functions (threads). Perhaps this is too much to ask for the compile-time system since the borrowing wouldn't happen for "whole objects" (a single big array) but for "part objects" (references to subblocks). I don't know of any languages that can handle whole-part relations by constructor (Hylo / Val supposedly does so, but I failed to see how in real-world examples). If you have any ideas let me know. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @seanbaxter , Alfredo here.
I wanted to let you know that I worked around all the errors in my code that circle complained about and other compilers didn't complain about.
So, circle b170 can compile the library (tests).
https://gitlab.com/correaa/boost-multi/-/jobs/2412971718
Thank you very much, I mention your compiler as one of the compatible compilers, https://gitlab.com/correaa/boost-multi#dependecies-and-compiler-requirements
I will keep your compiler in the CI so if something else arises, I will let you know.
Having said that, there are still about a dozen locations that I have to workaround by plainly commenting code.
Fortunately they are in tests only and not in the header file.
There are two types of problems, crashes and not recognizing constexpr that other compiler do recognize as constexpr (may be you are right and other compilers are wrong, I don't know).
These are all the places (file and line number and at the reason at the end of the line) I had to comment.
all these files are here: https://gitlab.com/correaa/boost-multi/-/tree/master/test
If it helps debugging, this is how I compile the library (tests):
The text was updated successfully, but these errors were encountered: