Closed for major changes; release freeze approaching
Boosters, Per release calendar, the release branch is closed for major changes now. On next Monday, Jan 11, the branch will be closed for all changes except by permission. What constitutes major change is up to you, but please exercise caution with commits. Now, I believe we have two outstanding issues: - uuid is still not merged to release branch - we still have issues with Boost.Test, see: http://permalink.gmane.org/gmane.comp.lib.boost.devel/198282 - release branch has 20 regressions, and 138 new failures. functional/hash, numeric/interval and regex are the libraries with regressions. I'd appreciate if maintainers of those libraries act on regressions, and other maintainers examine "new" failures. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus
2010/1/5 Vladimir Prus <vladimir@codesourcery.com>:
functional/hash, numeric/interval and regex are the libraries with regressions.
The hash failures aren't really regressions. I turned on warnings as errors, and then the integer library started producing a warning. They'll be fixed once I merge. Daniel
Daniel James wrote:
2010/1/5 Vladimir Prus <vladimir@codesourcery.com>:
functional/hash, numeric/interval and regex are the libraries with regressions.
The hash failures aren't really regressions. I turned on warnings as errors, and then the integer library started producing a warning. They'll be fixed once I merge.
Ok, good to know! - Volodya
functional/hash, numeric/interval and regex are the libraries with regressions.
There's something strange going on here: Math lib: mpfr_concept_check and ntl_concept_check are marked up in expected_failures.xml (and have been since they were added - they rely on external third party software to pass), but are still being shown as regressions. test_hypergeometric_dist2 and test_hypergeometric_dist3 are failing due to internal compiler errors in msvc-8, but strangely they compile just fine locally. I don't really see what I can do here... Regex lib: regex_timer is failing on two platforms (including vc-8) but works fine here, and in any case there are no pertinent changes as far as I can tell. The program output here: http://tinyurl.com/yzm2xpm suggests it ran OK to completion, and yet it's still marked as failing, is the full build log available somewhere? TR1/type_traits Libs: Failures form vc7.1 and things that aren't supported with that compiler - it's possible that they're work-round-able, but will mark up for now. John.
2010/1/6 John Maddock <john@johnmaddock.co.uk>:
mpfr_concept_check and ntl_concept_check are marked up in expected_failures.xml (and have been since they were added - they rely on external third party software to pass), but are still being shown as regressions.
They're currently only marked up on the release branch. Daniel
mpfr_concept_check and ntl_concept_check are marked up in expected_failures.xml (and have been since they were added - they rely on external third party software to pass), but are still being shown as regressions.
They're currently only marked up on the release branch.
Sure... but this *is* the release branch we're looking at right? John. PS will mark up Trunk as well though...
John Maddock <john <at> johnmaddock.co.uk> writes:
Regex lib:
regex_timer is failing on two platforms (including vc-8) but works fine here, and in any case there are no pertinent changes as far as I can tell. The program output here: http://tinyurl.com/yzm2xpm suggests it ran OK to completion, and yet it's still marked as failing, is the full build log available somewhere?
The full log says that both regex_timer and regex_regress_threaded are exceeding the test time limit (that's with the default 300 second limit).
The hash failures aren't really regressions. I turned on warnings as errors, and then the integer library started producing a warning. They'll be fixed once I merge.
Looks like gcc on Darwin is producing warnings from cstdint.hpp that regular gcc on Linux doesn't - I thought I had all those warnings quashed as well :-( Any Darwin developers got any ideas? Thanks, John.
2010/1/6 John Maddock <john@johnmaddock.co.uk>:
Looks like gcc on Darwin is producing warnings from cstdint.hpp that regular gcc on Linux doesn't - I thought I had all those warnings quashed as well :-(
Any Darwin developers got any ideas?
I think it's a bug in the gcc 4.0 library, not a darwin bug (it doesn't happen in darwin 4.2). This is what happens: #include <vector> // In cstdint.hpp: #define __STDC_CONSTANT_MACROS #include <stdint.h> 'vector' includes 'stdint.h' before __STDC_CONSTANT_MACROS is defined, so the macro has no effect and the integer constant macros (INT8_C etc) aren't defined. So boost's version is used which causes the warning. The easy workaround is to define the system header pragma immediately before the warning is generated (patch attached). Technically, there's an ODR violation since INT8_C can be defined differently in different units, but I don't think that's a real problem. Daniel
participants (4)
-
Daniel James -
John Maddock -
Richard Webb -
Vladimir Prus