* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
@ 2013-10-17 9:01 ` paolo.carlini at oracle dot com
2013-10-17 10:24 ` glisse at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-10-17 9:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed| |2013-10-17
Summary|error: converting to ‘const |[lwg/2193] error:
|std::vector<std::basic_stri |converting to ‘const
|ng<char> >’ from |std::vector<std::basic_stri
|initializer list would use |ng<char> >’ from
|explicit constructor |initializer list would use
| |explicit constructor
Ever confirmed|0 |1
--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
At present, 4.9 is conforming to C++11 and 4.8 is not. In general this is
tracked in http://cplusplus.github.io/LWG/lwg-active.html#2193 and as you can
see there are clear issues with the separate non-explicit default constructor
vs explicit instantiations.
>From gcc-bugs-return-432038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 17 09:11:57 2013
Return-Path: <gcc-bugs-return-432038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7233 invoked by alias); 17 Oct 2013 09:11:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7187 invoked by uid 48); 17 Oct 2013 09:11:52 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58764] [lwg/2193] error:=?UTF-8?Q? converting to ‘const std?=::vector<std::basic_string<char> >=?UTF-8?Q?’ from initializer list would use explicit constructor?Date: Thu, 17 Oct 2013 09:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: SUSPENDED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58764-4-ldBhKWVvvB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58764-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58764-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg01182.txt.bz2
Content-length: 898
http://gcc.gnu.org/bugzilla/show_bug.cgi?idX764
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
As Marc clarified elsewhere before some patches of him, pre-4.9 we were
inconsistent about this, thus I understand it could also make sense to resolve
the inconsistency toward separate default constructor everywhere (slightly
against the letter of C++11 as-is) or even not resolving it at all, leave these
bits alone for now and wait for 2193 to be resolved one way or another. Maybe
Marc has a personal opinion. How many separate default constructor we used to
have and how many constructors the other way?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
2013-10-17 9:01 ` [Bug libstdc++/58764] [lwg/2193] " paolo.carlini at oracle dot com
@ 2013-10-17 10:24 ` glisse at gcc dot gnu.org
2013-10-17 10:46 ` paolo.carlini at oracle dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-10-17 10:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #2)
> As Marc clarified elsewhere before some patches of him, pre-4.9 we were
> inconsistent about this, thus I understand it could also make sense to
> resolve the inconsistency toward separate default constructor everywhere
> (slightly against the letter of C++11 as-is) or even not resolving it at
> all, leave these bits alone for now and wait for 2193 to be resolved one way
> or another. Maybe Marc has a personal opinion. How many separate default
> constructor we used to have and how many constructors the other way?
Mostly normal mode had separate constructors and debug/profile had merged
constructors.
I am in favor of applying the proposed resolution and having separate
constructors everywhere: I don't care about explicit instantiation of the whole
container class, and it has more functionality. We may want to put a
noexcept(is_nothrow_default_constructible<_Alloc>::value) on the default
constructors, not to lose anything compared to the current code.
I won't write the patch myself.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
2013-10-17 9:01 ` [Bug libstdc++/58764] [lwg/2193] " paolo.carlini at oracle dot com
2013-10-17 10:24 ` glisse at gcc dot gnu.org
@ 2013-10-17 10:46 ` paolo.carlini at oracle dot com
2013-10-17 11:46 ` glisse at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-10-17 10:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Ok, let's wait a bit more, possibly until the next meeting, and then we'll make
the final decision.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (2 preceding siblings ...)
2013-10-17 10:46 ` paolo.carlini at oracle dot com
@ 2013-10-17 11:46 ` glisse at gcc dot gnu.org
2013-10-17 13:01 ` paolo.carlini at oracle dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-10-17 11:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #4)
> Ok, let's wait a bit more, possibly until the next meeting,
The next meeting will be too late for 4.9, so that means sticking to what we
have now.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (3 preceding siblings ...)
2013-10-17 11:46 ` glisse at gcc dot gnu.org
@ 2013-10-17 13:01 ` paolo.carlini at oracle dot com
2013-10-30 13:30 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-10-17 13:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I'm not sure at all about the dates. Anyway, the DR isn't resolved yet.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (4 preceding siblings ...)
2013-10-17 13:01 ` paolo.carlini at oracle dot com
@ 2013-10-30 13:30 ` redi at gcc dot gnu.org
2014-01-07 11:53 ` [Bug libstdc++/58764] [4.9 Regression] " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2013-10-30 13:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
IMHO following the precise wording of the standard is a mistake, the P/R is
obviously correct and fixing it for 4.9 is necessary. Just IMHO though :)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (5 preceding siblings ...)
2013-10-30 13:30 ` redi at gcc dot gnu.org
@ 2014-01-07 11:53 ` rguenth at gcc dot gnu.org
2014-01-09 12:55 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-07 11:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.9.0
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (6 preceding siblings ...)
2014-01-07 11:53 ` [Bug libstdc++/58764] [4.9 Regression] " rguenth at gcc dot gnu.org
@ 2014-01-09 12:55 ` redi at gcc dot gnu.org
2014-01-22 19:47 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2014-01-09 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #5)
> (In reply to Paolo Carlini from comment #4)
> > Ok, let's wait a bit more, possibly until the next meeting,
>
> The next meeting will be too late for 4.9, so that means sticking to what we
> have now.
"What we have now" for most users is what we shipped in all previous releases
up to 4.8, which allows this:
std::vector<int> v = {};
Rejecting that is a pretty serious regression.
The explicitness of the container constructors had already been questioned by
LWG 2193 when we made the change, so I consider it a mistake to make an
breaking change to conform to wording that is potentially defective.
I'm going to restore the previous constructors (so 4.9 will stick with what we
have now) until the DR is resolved one way or another.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (7 preceding siblings ...)
2014-01-09 12:55 ` redi at gcc dot gnu.org
@ 2014-01-22 19:47 ` redi at gcc dot gnu.org
2014-01-22 23:51 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2014-01-22 19:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Wed Jan 22 19:46:44 2014
New Revision: 206939
URL: http://gcc.gnu.org/viewcvs?rev=206939&root=gcc&view=rev
Log:
PR libstdc++/58764
* include/bits/stl_deque.h (deque::deque(const allocator_type&):
Split into separate default constructor and constructor taking
allocator.
* include/bits/stl_list.h (list::list(const allocator_type&): Likewise.
* include/bits/stl_vector.h (vector::vector(const allocator_type&):
Likewise.
* include/debug/deque (deque::deque(const allocator_type&)): Likewise.
* include/debug/list (list::list(const _Allocator&)): Likewise.
* include/debug/map.h (map::map(const _Compare&, const _Allocator&)):
Likewise.
* include/debug/multimap.h
(multimap::multimap(const _Compare&, const _Allocator&)): Likewise.
* include/debug/set.h (set::set(const _Compare&, const _Allocator&)):
Likewise.
* include/debug/multiset.h
(multiset::multiset(const _Compare&, const _Allocator&)): Likewise.
* include/debug/vector (vector::vector(const allocator_type&)):
Likewise.
* include/profile/deque (deque::deque(const _Allocator&)): Likewise.
* include/profile/list (list::list(const _Allocator&)): Likewise.
* include/profile/map.h
(map::map(const _Compare&, const _Allocator&)): Likewise.
* include/profile/multimap.h
(multimap::multimap(const _Compare&, const _Allocator&)): Likewise.
* include/profile/set.h
(set::set(const _Compare&, const _Allocator&)): Likewise.
* include/profile/multiset.h
(multiset::multiset(const _Compare&, const _Allocator&)): Likewise.
* include/profile/vector (vector::vector(const _Allocator&)):
Likewise.
* testsuite/23_containers/deque/58764.cc: New.
* testsuite/23_containers/list/58764.cc: New.
* testsuite/23_containers/map/58764.cc: New.
* testsuite/23_containers/multimap/58764.cc: New.
* testsuite/23_containers/set/58764.cc: New.
* testsuite/23_containers/multiset/58764.cc: New.
* testsuite/23_containers/vector/58764.cc: New.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* testsuite/23_containers/deque/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/insert_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
Likewise.
Added:
trunk/libstdc++-v3/testsuite/23_containers/deque/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/map/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multimap/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/58764.cc
- copied, changed from r206938,
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_deque.h
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/include/bits/stl_vector.h
trunk/libstdc++-v3/include/debug/deque
trunk/libstdc++-v3/include/debug/list
trunk/libstdc++-v3/include/debug/map.h
trunk/libstdc++-v3/include/debug/multimap.h
trunk/libstdc++-v3/include/debug/multiset.h
trunk/libstdc++-v3/include/debug/set.h
trunk/libstdc++-v3/include/debug/vector
trunk/libstdc++-v3/include/profile/deque
trunk/libstdc++-v3/include/profile/list
trunk/libstdc++-v3/include/profile/map.h
trunk/libstdc++-v3/include/profile/multimap.h
trunk/libstdc++-v3/include/profile/multiset.h
trunk/libstdc++-v3/include/profile/set.h
trunk/libstdc++-v3/include/profile/vector
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (8 preceding siblings ...)
2014-01-22 19:47 ` redi at gcc dot gnu.org
@ 2014-01-22 23:51 ` redi at gcc dot gnu.org
2014-01-22 23:57 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2014-01-22 23:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Wed Jan 22 23:50:58 2014
New Revision: 206946
URL: http://gcc.gnu.org/viewcvs?rev=206946&root=gcc&view=rev
Log:
PR libstdc++/58764 (again)
* include/bits/stl_list.h (list): Make default constructor's exception
specification conditional.
* include/bits/stl_vector.h (vector): Likewise.
* testsuite/util/testsuite_allocator.h (SimpleAllocator): Add noexcept
to default constructor.
* testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/list/requirements/dr438/insert_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
Likewise.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/include/bits/stl_vector.h
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (9 preceding siblings ...)
2014-01-22 23:51 ` redi at gcc dot gnu.org
@ 2014-01-22 23:57 ` redi at gcc dot gnu.org
2014-01-23 10:40 ` glisse at gcc dot gnu.org
2014-01-23 10:44 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2014-01-22 23:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
On trunk now we have separate (non-explicit) default constructors for deque,
list, vector, map, multimap, set and multiset. Debug and profile modes should
be consistent with normal mode.
We still have explicit default constructors for the C++11 containers,
forward_list and unordered_xxx, which I suggest revisiting when LWG 2193 is
resolved, but the regression is fixed.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (10 preceding siblings ...)
2014-01-22 23:57 ` redi at gcc dot gnu.org
@ 2014-01-23 10:40 ` glisse at gcc dot gnu.org
2014-01-23 10:44 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-01-23 10:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #13)
> On trunk now we have separate (non-explicit) default constructors for deque,
> list, vector, map, multimap, set and multiset.
Thanks!
> Debug and profile modes should be consistent with normal mode.
I guess consistency for the noexcept specification is not as important.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor
2013-10-17 8:04 [Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor markus at trippelsdorf dot de
` (11 preceding siblings ...)
2014-01-23 10:40 ` glisse at gcc dot gnu.org
@ 2014-01-23 10:44 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2014-01-23 10:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #14)
> I guess consistency for the noexcept specification is not as important.
Since those noexcept specs are not required by the standard I'm not too
concerned about it for now. It would be nice to address at some point, so that
debug mode containers take the same code paths for anything that depends on
nothrow specs.
I don't care about profile mode at all ;-)
Thanks for your help and code reviews with this.
^ permalink raw reply [flat|nested] 14+ messages in thread