From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8878 invoked by alias); 1 Jan 2010 03:55:11 -0000 Received: (qmail 8784 invoked by uid 48); 1 Jan 2010 03:54:58 -0000 Date: Fri, 01 Jan 2010 03:55:00 -0000 Message-ID: <20100101035458.8783.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/21772] exception safety testing In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bkoz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00006.txt.bz2 ------- Comment #18 from bkoz at gcc dot gnu dot org 2010-01-01 03:54 ------- > multiset error ... was bogus. I adjusted the traits to fix this. > The std::array error seems indeed bogus: if I'm not wrong, it happens when > swapping arrays, and there are no guarantees that the operation doesn't throw > for std::array, because it's requires to just swap the ranges, thus copy > construct and copy assign each array element. It does happen when swapping arrays. I believe that array::swap does have a strong requirement via 23.2.1 p 10, but have xfailed this for the moment. In addition, I have removed the throwing on user defined ctors for throw_value_* via _GLIBCXX_IS_AGGREGATE to simulate a more aggregate-ish thing. However, even aggregates can have assignment operators and other operator actions that throw, and this still fails. (And note the value_type of std::array can have user defined ctors ie 8.5.1 p 13). > Another thing I noticed, about basic_string, something seems inappropriate for > it in the framework, since the value_type must be a POD! Four specializations are defined: char, wchar_t, char16_t, char32_t. That is the only part of basic_string that is special WRT container requirements that I can see. ? I went ahead and checked this in, xfailing the following failures: FAIL: 21_strings/basic_string/requirements/exception/propagation_consistent.cc execution test FAIL: 23_containers/array/requirements/exception/generation_prohibited.cc execution test FAIL: 23_containers/deque/requirements/exception/generation_prohibited.cc execution test FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc execution test FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc execution test I believe that deque/.../propagation_consistent.cc will have to be modified to take into account 23.3.2.3, and copy/assignment should be elided in this case (and vector via 23.3.6.4) Regardless, this can be tweaked in place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772