Opened 13 years ago
Closed 10 years ago
#4080 closed Bugs (fixed)
Various compilers need BOOST_NO_COMPLETE_VALUE_INITIALIZATION
| Reported by: | niels_dekker | Owned by: | niels_dekker |
|---|---|---|---|
| Milestone: | Boost 1.43.0 | Component: | config |
| Version: | Boost 1.42.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
John Maddock has just added my boost_no_complete_value_initialization tests to the trunk: https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_init.ipp [61153], which is likely to cause some regression failures. This ticket is there to remind me to keep an eye at the regression page: http://www.boost.org/development/tests/trunk/developer/config_.html And to define the new defect macro, BOOST_NO_COMPLETE_VALUE_INITIALIZATION, for those compilers that appear to get those regression failures.
Moreover, this ticket allows archiving the regression failure output for those compilers, before those failures are suppressed by means of the defect macro.
Related ticket: #3869, "Unconditional call to memset in value_initialized()", reported by Aleksey Gurtovoy.
Related mailing list item: [boost] [config] New defect macro:BOOST_NO_COMPLETE_VALUE_INITIALIZATION
Change History (16)
follow-up: 2 comment:1 by , 13 years ago
comment:2 by , 13 years ago
I just added BOOST_NO_COMPLETE_VALUE_INITIALIZATION to https://svn.boost.org/svn/boost/trunk/boost/config/compiler/vacpp.hpp because IBM's XL C/C++ for AIX V10.1.0.0 did not value-initialize enum_holder_and_int(), virtual_destructor_holder(), and non_pod_class() from
https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_init.ipp revision [61436], according to the Config/trunk regression data provided by IBM_Canada_Ltd.
comment:3 by , 12 years ago
follow-up: 5 comment:4 by , 12 years ago
comment:5 by , 12 years ago
Adding BOOST_NO_COMPLETE_VALUE_INITIALIZATION to http://svn.boost.org/svn/boost/trunk/boost/config/compiler/borland.hpp ([61652]) fixed the related regression failures of siliconman/borland-5.9.3 (config_test + config_test_threaded), but it did not fix any regression failure of siliconman/borland-6.1.3, siliconman/borland-6.2.1, codegear/borland-cb2009, or borland-cb2010. So the defect macro still needs to be added to http://svn.boost.org/svn/boost/trunk/boost/config/compiler/codegear.hpp
comment:6 by , 12 years ago
comment:7 by , 12 years ago
comment:8 by , 12 years ago
comment:9 by , 12 years ago
comment:10 by , 12 years ago
comment:11 by , 12 years ago
comment:12 by , 12 years ago
comment:13 by , 12 years ago
comment:14 by , 12 years ago
comment:16 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Thanks, Vicente. I agree with you; I'll close the ticket. Of course future compiler versions might need this defect-macro as well...
Note that for Microsoft Visual C++, with revision [78468] the defect-macro is defined unconditionally (independent of its compiler version). Unfortunately the current Boost Config test cannot detect when this defect-macro is defined unnecessarily. (If a future version of Visual C++ would ever completely implement value-initialization, BOOST_NO_COMPLETE_VALUE_INITIALIZATION would still remain there for this compiler.) But that issue is beyond the scope of this ticket.
(In [61516]) Added BOOST_NO_COMPLETE_VALUE_INITIALIZATION to IBM XL C++ <= V10.1.0 (trunk), see #4080.