https://boost-consulting.com/trac/projects/boost/build/trunk reveals that https://boost-consulting.com/trac/projects/boost/changeset/41919 introduced a failing test of the utility library. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
https://boost-consulting.com/trac/projects/boost/build/trunk reveals that https://boost-consulting.com/trac/projects/boost/changeset/41919 introduced a failing test of the utility library.
Thanks for reminding me, Dave. The test failure actually indicates that the MSVC-workaround of value_initialized that I committed a while ago to the trunk has a bug: when a value_initialized<T> object is copied, the wrapped T object isn't copied properly. If T has an accessible copy constructor, it should be called when copy-constructing a value_initialized<T>. And if T has an accessible copy assignment operator, it should be called when assigning a value_initialized<T>. I have just committed a fix for this bug to the trunk: http://svn.boost.org/trac/boost/changeset/41942 Luckily the bug wasn't yet released! I mean, it isn't yet in Boost release version 1.34.1, and I hope we can take it out of the release branch. The commit (changeset [41942]) aims to fix some other issues as well. Fernando Cacciola (the owner of value_init) and I also decided to no longer distinguish between a "workaround version" and a non-workaround version of value_initialized<T>. Until now the workaround was only for MSVC. But it has appeared that various other compilers have value-initialization related issues: GCC Bug 30111 - Value-initialization of POD base class doesn't initialize members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 GCC Bug 33916 - Default constructor fails to initialize array members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916 Borland Report 51854 - Value-initialization: POD struct should be zero-initialized http://qc.codegear.com/wc/qcmain.aspx?d=51854 I recently added tests on these issues to value_init_test, and they caused a test failures on a majority of the test platforms, at http://beta.boost.org/development/tests/trunk/developer/utility_.html In general, those compilers that don't support value-initialization well forget to zero-initialize the POD-members of a type T, in some cases... The workaround is basically as follows: The constructor of value_initialized<T> stores the bytes of an instance of T in an aligned_storage::type object, whose bytes are set to zero, followed by a placement new. Hopefully the new value_init.hpp will make an end to the test failures. If so, I hope we can still merge the trunk version with the release version, 1.35.0. Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
on Sun Dec 09 2007, Niels Dekker - mail address until 2008-12-31 <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> wrote:
David Abrahams wrote:
https://boost-consulting.com/trac/projects/boost/build/trunk reveals that https://boost-consulting.com/trac/projects/boost/changeset/41919 introduced a failing test of the utility library.
Thanks for reminding me, Dave. The test failure actually indicates that the MSVC-workaround of value_initialized that I committed a while ago to the trunk has a bug: when a value_initialized<T> object is copied, the wrapped T object isn't copied properly. If T has an accessible copy constructor, it should be called when copy-constructing a value_initialized<T>. And if T has an accessible copy assignment operator, it should be called when assigning a value_initialized<T>. I have just committed a fix for this bug to the trunk: http://svn.boost.org/trac/boost/changeset/41942
Unfortunately, as https://boost-consulting.com/trac/projects/boost/build/trunk shows, that appears to have broken Boost.Python on Linux/GCC.
Luckily the bug wasn't yet released! I mean, it isn't yet in Boost release version 1.34.1, and I hope we can take it out of the release branch.
The commit (changeset [41942]) aims to fix some other issues as well. Fernando Cacciola (the owner of value_init) and I also decided to no longer distinguish between a "workaround version" and a non-workaround version of value_initialized<T>.
Until now the workaround was only for MSVC. But it has appeared that various other compilers have value-initialization related issues:
GCC Bug 30111 - Value-initialization of POD base class doesn't initialize members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 GCC Bug 33916 - Default constructor fails to initialize array members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916 Borland Report 51854 - Value-initialization: POD struct should be zero-initialized http://qc.codegear.com/wc/qcmain.aspx?d=51854
I recently added tests on these issues to value_init_test, and they caused a test failures on a majority of the test platforms, at http://beta.boost.org/development/tests/trunk/developer/utility_.html
I guess maybe that explains the Boost.Python test failures?
In general, those compilers that don't support value-initialization well forget to zero-initialize the POD-members of a type T, in some cases... The workaround is basically as follows: The constructor of value_initialized<T> stores the bytes of an instance of T in an aligned_storage::type object, whose bytes are set to zero, followed by a placement new.
Hopefully the new value_init.hpp will make an end to the test failures. If so, I hope we can still merge the trunk version with the release version, 1.35.0.
I'm sure that once we get things stabilized we'll have no problem getting it into the release branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I have just committed a fix for this bug to the trunk: http://svn.boost.org/trac/boost/changeset/41942
Unfortunately, as https://boost-consulting.com/trac/projects/boost/build/trunk shows, that appears to have broken Boost.Python on Linux/GCC.
Do you mean the failures at python/test/try.cpp ? I have no clue how those failures could possibly be caused by value_init. Do you? https://boost-consulting.com/trac/projects/boost/build-details/trunk/795/pyt... says: File "newtest.py", line 7, in __main__ Failed example: from m2 import * Exception raised: Traceback (most recent call last): File "doctest.py", line 1212, in __run compileflags, 1) in test.globs File "<doctest __main__[1]>", line 1, in <module> from m2 import * ImportError: No module named m2 [...]
I recently added tests on these issues to value_init_test, and they caused a test failures on a majority of the test platforms, at http://beta.boost.org/development/tests/trunk/developer/utility_.html
I guess maybe that explains the Boost.Python test failures?
Most of the tests that I added to value_init_test actually tested the compiler implementation of value-initialization. (Except for the most recently added test, changeset [41919], which tested copying value_initialized<T> objects.) It's still unclear to me how providing a workaround to those compiler issues could cause Boost.Python test failures... The good news: the value_init tests at beta.boost.org now have "unexpected" passes for Sandia-gcc-64: http://beta.boost.org/development/tests/trunk/developer/utility_.html I expect other platforms to go green on the value_init test soon... :-) Kind regards, Niels
on Mon Dec 10 2007, "Niels Dekker - mail address until 2008-12-31" <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> wrote:
David Abrahams wrote:
I have just committed a fix for this bug to the trunk: http://svn.boost.org/trac/boost/changeset/41942
Unfortunately, as https://boost-consulting.com/trac/projects/boost/build/trunk shows, that appears to have broken Boost.Python on Linux/GCC.
Do you mean the failures at python/test/try.cpp ? I have no clue how those failures could possibly be caused by value_init. Do you?
https://boost-consulting.com/trac/projects/boost/build-details/trunk/795/pyt... says: File "newtest.py", line 7, in __main__ Failed example: from m2 import * Exception raised: Traceback (most recent call last): File "doctest.py", line 1212, in __run compileflags, 1) in test.globs File "<doctest __main__[1]>", line 1, in <module> from m2 import * ImportError: No module named m2 [...]
Nope. And they disappear in the next revision just as mysteriously.
I recently added tests on these issues to value_init_test, and they caused a test failures on a majority of the test platforms, at http://beta.boost.org/development/tests/trunk/developer/utility_.html
I guess maybe that explains the Boost.Python test failures?
Most of the tests that I added to value_init_test actually tested the compiler implementation of value-initialization. (Except for the most recently added test, changeset [41919], which tested copying value_initialized<T> objects.) It's still unclear to me how providing a workaround to those compiler issues could cause Boost.Python test failures...
The good news: the value_init tests at beta.boost.org now have "unexpected" passes for Sandia-gcc-64: http://beta.boost.org/development/tests/trunk/developer/utility_.html I expect other platforms to go green on the value_init test soon... :-)
Nifty :-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
David Abrahams -
Niels Dekker - mail address until 2008-12-31