[Bug libstdc++/58764] New: error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[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]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764

            Bug ID: 58764
           Summary: error: converting to ‘const
                    std::vector<std::basic_string<char> >’ from
                    initializer list would use explicit constructor
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markus at trippelsdorf dot de

aria2 fails to compile with gcc-4.8:

download_helper.cc: In member function ‘void
aria2::{anonymous}::AccRequestGroup::operator()(const string&)’:
download_helper.cc:373:64: error: converting to ‘const
std::vector<std::basic_string<char> >’ from initializer list would use explicit
constructor ‘std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp
= std::basic_string<char>; _Alloc = std::allocator<std::basic_string<char> >;
std::vector<_Tp, _Alloc>::allocator_type =
std::allocator<std::basic_string<char> >]’
           (createBtRequestGroup(uri, option_, {}, torrent.get()));
                                                                ^

Reduced:

markus@x4 tmp % cat test.cpp
#include <vector>
#include <string>

void foo (const std::vector<std::string>& test)
{
}
void bar ()
{
  foo ({});
}

markus@x4 tmp % g++ -std=c++11 -c test.cpp
test.cpp: In function ‘void bar()’:
test.cpp:9:10: error: converting to ‘const std::vector<std::basic_string<char>
>’ from initializer list would use explicit constructor ‘std::vector<_Tp,
_Alloc>::vector(const allocator_type&) [with _Tp = std::basic_string<char>;
_Alloc = std::allocator<std::basic_string<char> >; std::vector<_Tp,
_Alloc>::allocator_type = std::allocator<std::basic_string<char> >]’
   foo ({});
          ^

markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/g++ -std=c++11 -c
test.cpp
markus@x4 tmp % clang++ -stdlib=libc++ -std=c++11 -c test.cpp
markus@x4 tmp %
>From gcc-bugs-return-432033-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 17 08:14:31 2013
Return-Path: <gcc-bugs-return-432033-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10489 invoked by alias); 17 Oct 2013 08:14:30 -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 10429 invoked by uid 55); 17 Oct 2013 08:14:27 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/58267] Alignment specifier allowed within array declarator;
Date: Thu, 17 Oct 2013 08:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58267-4-D7aiLryJeR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58267-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58267-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/msg01177.txt.bz2
Content-length: 962

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX267

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Oct 17 08:14:23 2013
New Revision: 203742

URL: http://gcc.gnu.org/viewcvs?rev 3742&root=gcc&view=rev
Log:
    PR c/58267
c/
    * c-parser.c (c_parser_declspecs): Add alignspec_ok parameter.
    Document syntax of the array-declarator.
    (c_parser_declspecs) <RID_ALIGNAS>: Bail out if alignment specs
    are not permitted.
    (c_parser_declaration_or_fndef): Adjust c_parser_declspecs call.
    (c_parser_struct_declaration): Likewise.
    (c_parser_declarator): Likewise.
    (c_parser_direct_declarator_inner): Likewise.
    (c_parser_parameter_declaration): Likewise.
    (c_parser_type_name): Likewise.
testsuite/
    * gcc.dg/c1x-align-5.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/c1x-align-5.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-parser.c
    trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[paolo.carlini at oracle dot com]

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?

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[glisse at gcc dot gnu.org]

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.

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[paolo.carlini at oracle dot com]

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.

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[glisse at gcc dot gnu.org]

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.

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[paolo.carlini at oracle dot com]

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.

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector<std::basic_string<char> >’ from initializer list would use explicit constructor

[redi at gcc dot gnu.org]

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 :)

[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

[rguenth at gcc dot gnu.org]

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

[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

[redi at gcc dot gnu.org]

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.

[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

[redi at gcc dot gnu.org]

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

[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

[redi at gcc dot gnu.org]

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

[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

[redi at gcc dot gnu.org]

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.

[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

[glisse at gcc dot gnu.org]

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.

[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

[redi at gcc dot gnu.org]

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.