Re: [boost] [integer][math]Heads up on revised gcd/lcm code

Subject: Re: [boost] [integer][math]Heads up on revised gcd/lcm code
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-04-26 18:46:44

> I have tested sun 12.2 through 12.5 with stlport and running the 
> integer lasts from the latest 'develop'. 

Thanks for this!

> My user-config.jam entry for each version has:
>
>     <cxxflags>-std=sun03
>     <cxxflags>-library=stlport4
>     <linkflags>-std=sun03
>     <linkflags>-library=stlport4
>     <cxxflags>-features=tmplife
>     <cxxflags>-features=tmplrefstatic ;
>
> I get, starting from the latest:
>
> 12.5
>
> sun.compile.c++ 
> /home/fceldiener/build/boost/bin.v2/libs/integer/test/common_factor_test.test/sun-12.5stlport/debug/address-model-32/common_factor_test.o
>
> "../../../boost/rational.hpp", line 141: Error: The type 
> "boost::STATIC_ASSERTION_FAILURE<0>" is incomplete.
>
> "common_factor_test.cpp", line 327:     Where: While specializing 
> "boost::rational<my_wrapped_integer<int, 1>>".
>
> "common_factor_test.cpp", line 327:     Where: Specialized in 
> non-template code.
>
> 1 Error(s) detected.
>

This is now fixed in develop by altering the tests

This issue is caused (and would have been equally caused before) by 
simply including <boost/rational.hpp>.

The problem is that the tests use gcd<T>(arg1, arg2), but this causes 
all overloads of gcd to be instantiated on T, regardless of whether they 
will be selected, and the rational (or multiprecision) overloads may not 
compile for some random type T.  Changing to gcd(static_cast<T>(arg1), 
static_cast<T>(arg2)) fixes things for now.  It's probably possible to 
make this work if there was a real need, but since it has never worked 
before (the tests simply weren't exposing the issue) and no one has 
complained it's very low priority IMO.

>
> 12.4
>
> sun.compile.c++ 
> /home/fceldiener/build/boost/bin.v2/libs/integer/test/common_factor_test.test/sun-12.4stlport/debug/address-model-32/common_factor_test.o
>
> "../../../boost/integer/common_factor_rt.hpp", line 110: Warning: 
> Identifier expected instead of "}".

That's a bug in the header for C++98 compilers (extraneous , in enum 
declaration), fixed in develop.

I'm hoping the rest of the errors are cascading off this.

> 12.2
>
> ../../../boost/cstdint.hpp", line 381: Error: uintptr_t is not defined.
>
> appears for each test.

I've pushed a tentative fix to Boost.Config, but it's likely that this 
has never worked before either!

>
> I did not try 64-bit tests. Should I try with a higher -std=c++11 
> level with stlport ? I have separate jam entries which test each 
> version without the stlport library but with c++03 or c++11 as the 
> standard.
>

I don't believe it's possible to compile with both STLPort and C++11 or 
later as these use a different ABI.

There is one remaining failure with Oracle 12.5 in C++11 mode relating 
to how it handles variadic templates, I'll try to find a workaround for 
that later.

Many thanks for those tests!

John.

---
This email has been checked for viruses by AVG.
http://www.avg.com