Containers default initialization

[Jonathan Wakely]

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.