Re: Containers default initialization

[Jonathan Wakely <jwakely at redhat dot 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.