The testcase is:


struct f { void crash(); };

void bar(bool cond) {
    f t;
    if(cond)
        t.crash();
    //user(&t);
}

> This potentially leaks a byte of memory.  
The only way to access that byte is to use memcpy or via char. 
-ftrivial-auto-var-init is not designed for security this way but rather for normal code ...

IIRC atomic compare and swap will zero it out too ...

(In reply to Andrew Pinski from comment #2)
> The only way to access that byte is to use memcpy or via char. 
> -ftrivial-auto-var-init is not designed for security this way but rather for
> normal code ...

That's not what the manual says (emphasis mine):

"Initialize automatic variables with either a pattern or with zeroes to increase the security and predictability of a program by preventing **uninitialized memory disclosure** and use."

> IIRC atomic compare and swap will zero it out too ...

The std::atomic and std::atomic_ref compare_exchange members will zero it, but the compiler built-in won't.

(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The only way to access that byte is to use memcpy or via char. 
> > -ftrivial-auto-var-init is not designed for security this way but rather for
> > normal code ...
> 
> That's not what the manual says (emphasis mine):
> 
> "Initialize automatic variables with either a pattern or with zeroes to
> increase the security and predictability of a program by preventing
> **uninitialized memory disclosure** and use."

probably should add 'some' qualification here.

> > IIRC atomic compare and swap will zero it out too ...
> 
> The std::atomic and std::atomic_ref compare_exchange members will zero it,
> but the compiler built-in won't.

And fix the spelling of zeros, which is generally preferred to zeroes for the noun.