This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Containers default initialization
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 5 Jun 2017 12:31:42 +0100
- Subject: Re: Containers default initialization
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 75EC983F47
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 75EC983F47
- References: <5f2158d5-8996-31d3-cc4c-4058712f3f53@gmail.com>
On 04/06/17 22:26 +0200, François Dumont wrote:
Hi
I have eventually adapt the test to all containers and the result
is successful for map/set/unordered_map/unordered_set. It is failing
for deque/list/forward_list/vector/vector<bool>.
I even try to change the test to look at the difference between an
explicit call to the default constructor done through the placement
new call and an implicit call done on normal declaration. I wondered
if we would have the same kind of difference we have between a int i;
and a int i(); I tried to set the stack to ~0 before declaring the
instance. I know there is no guarantee on the content of the stack for
the following declaration but do you think it is reliable enough to
commit it ?
Ok to commit the successful tests ?
No, I'm seeing failures for some of these if I add
// { dg-options "-O0" }
Franckly I don't understand the result of those tests. I would
have expect map/set to fail and others to succeed. We might need help
from compiler guys, no ?
I think your tests are just insufficient. With optimisation enabled
(the testsuite uses -O2 by default) the compiler can remove the memset
just before the __aligned_buffer goes out of scope, because it is
unobservable in a correct program. This is similar to the situation
described at https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse
If I change the placement new-expressions to use default-init instead
of value-init and use -O0 then I see all four tests FAIL here:
test_type *tmp = ::new(buf._M_addr()) test_type; // not test_type()
VERIFY( tmp->get_allocator().state == 0 ); // FAIL
I haven't looked into why you're seeing failures for other containers,
but I'm definitely seeing the failures that I expected for maps and
sets.