Boost.Math svn/branches/release regressions flagged

[Bruce Simpson]

Hi guys,

Just doing a Boost regression run... Any ideas? 4 fails, in computing
float distance, over type double, with a large exponent.

Details here:
http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html

is linked off:
http://www.boost.org/development/tests/release/developer/math.html
See test_next link in left column of math.html, for affected code.

All other failures in Boost.Math, including this one, are down to
lacking gmpfrxx, or lacking long double support in FreeBSD:
http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html

This is not a prerequisite in the Boost port, and we don't package
gmpfrxx anywhere, so the concept checks fail.

cheers,
BMS

P.S. Boost has a fairly rich exposure to the platform, perhaps we can
get FreeBSD project resources for some occasional test coverage?

P.P.S The IPv6 multicast failures in Boost.ASIO are due to the test
machine having no v6 addresses other than ::1 (and no candidate default
route). That's the module I'm most concerned with right at this moment.
_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[David Schultz]

What architecture is this, and how new is the regression?

On Mon, Jul 06, 2009, Bruce Simpson wrote:

> Hi guys,
>
> Just doing a Boost regression run... Any ideas? 4 fails, in computing
> float distance, over type double, with a large exponent.
>
> Details here:
> http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html
>
> is linked off:
> http://www.boost.org/development/tests/release/developer/math.html
> See test_next link in left column of math.html, for affected code.
>
> All other failures in Boost.Math, including this one, are down to
> lacking gmpfrxx, or lacking long double support in FreeBSD:
> http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html
>
> This is not a prerequisite in the Boost port, and we don't package
> gmpfrxx anywhere, so the concept checks fail.
>
> cheers,
> BMS
>
> P.S. Boost has a fairly rich exposure to the platform, perhaps we can
> get FreeBSD project resources for some occasional test coverage?
>
> P.P.S The IPv6 multicast failures in Boost.ASIO are due to the test
> machine having no v6 addresses other than ::1 (and no candidate default
> route). That's the module I'm most concerned with right at this moment.

_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[Bruce Simpson]

David Schultz wrote:
> What architecture is this, and how new is the regression?
>  

This is i386, RELENG_7, tracking the Boost release branch (with their
regression test run.py script) as of yesterday.
_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[David Schultz]

I will try to take a look when I have time.  I'd be somewhat
surprised if this is a regression in FreeBSD, though, since
nothing that test_next or float_distance depend on (namely frexp
and ldexp) have changed recently.

On Mon, Jul 06, 2009, Bruce Simpson wrote:

> David Schultz wrote:
> >What architecture is this, and how new is the regression?
> >  
>
> This is i386, RELENG_7, tracking the Boost release branch (with their
> regression test run.py script) as of yesterday.
> _______________________________________________
> freebsd-standards@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-standards
> To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[Alexander Churanov]

Guys,

Please note that though testing boost using tools supplied by
boost.org can reveal actual issues in FreeBSD, this does not mean that
users of FreeBSD ports system will encounter all of them. Boost ports
contain patches that cut functionality that is not present in all
supported FreeBSD versions. Perhaps, this may seriously downgrade
issue severity.

For details, see http://wiki.freebsd.org/BoostPortingProject , section
"Known Issues".
I hope this information is useful.

Sincerely,
Alexander Churanov,
maintainer of devel/boost-* ports


2009/7/7 David Schultz <das@...>:

> I will try to take a look when I have time.  I'd be somewhat
> surprised if this is a regression in FreeBSD, though, since
> nothing that test_next or float_distance depend on (namely frexp
> and ldexp) have changed recently.
>
> On Mon, Jul 06, 2009, Bruce Simpson wrote:
>> David Schultz wrote:
>> >What architecture is this, and how new is the regression?
>> >
>>
>> This is i386, RELENG_7, tracking the Boost release branch (with their
>> regression test run.py script) as of yesterday.
>> _______________________________________________
>> freebsd-standards@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-standards
>> To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."
>

_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[Bruce Evans-4]

On Mon, 6 Jul 2009, Bruce Simpson wrote:

> Just doing a Boost regression run... Any ideas? 4 fails, in computing float
> distance, over type double, with a large exponent.

Is this the bug fixed by gcc change 129199?

If not, it might be a gcc bug or the test assuming that extra precision is
available.  You can probably eliminate precision bugs (including gcc bugs
related to precision) by testing on amd64.  The tests seemed to be compiled
with -O0, so maybe they are avoiding some precision bugs intentionally.  I
sometimes need more than -O0 to avoid precision bugs.

> Details here:
> http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html
>
> is linked off:
> http://www.boost.org/development/tests/release/developer/math.html
> See test_next link in left column of math.html, for affected code.

I couldn't see exactly what it is doing (does it call any libm functions?)
and would find it too hard to build the whole tests.

> All other failures in Boost.Math, including this one, are down to lacking
> gmpfrxx, or lacking long double support in FreeBSD:
> http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html
>
> This is not a prerequisite in the Boost port, and we don't package gmpfrxx
> anywhere, so the concept checks fail.

Looks like most things pass, but how much does leaving out long double tests
lose?

Bruce
_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[Bruce Simpson]

JFYI:    The HEAD/amd64 regression run was fubar -- got bitten by this
issue:
    http://lists.boost.org/boost-build/2008/10/20471.php

I've manually patched it and am re-running the test on ref8.freebsd.org now.

cheers,
BMS
_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."

[Bruce Simpson]

Bruce Evans wrote:
> On Mon, 6 Jul 2009, Bruce Simpson wrote:
>
>> Just doing a Boost regression run... Any ideas? 4 fails, in computing
>> float distance, over type double, with a large exponent.
>
> Is this the bug fixed by gcc change 129199?

No, this GCC bug was related to some global 'using' declarations. I have
a patch and am awaiting clearance from re@ to commit it. Only a few of
the tests in an otherwise clean run on FreeBSD 7.2/i386 are affected by
this, and the bug is part of the prior GCC 4.2.1 train. It's a one line
fix for the DWARF output module.

>
> If not, it might be a gcc bug or the test assuming that extra
> precision is
> available.  You can probably eliminate precision bugs (including gcc bugs
> related to precision) by testing on amd64.  The tests seemed to be
> compiled
> with -O0, so maybe they are avoiding some precision bugs
> intentionally.  I
> sometimes need more than -O0 to avoid precision bugs.

We've got other problems on FreeBSD with Boost right now. At the moment.
the Boost.Build GCC glue is assuming that it can put lib32 into the link
line, and rtld paths. Obviously, our runtime linker hates this, which is
why we have lots of FAIL for amd64. I will be working with the Boost
people to get the change which caused this backed out, as it seems that
it isn't needed anywhere else, either.

Until we get this resolved, it's difficult to test w/o
--disable-long-double and on i386.

>
> I couldn't see exactly what it is doing (does it call any libm
> functions?)
> and would find it too hard to build the whole tests.

Yes, Boost.Math is using libm extensively.

thanks,
BMS
_______________________________________________
freebsd-standards@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@..."