jfb added a comment.

In D68115#1962833 <https://reviews.llvm.org/D68115#1962833>, @rsmith wrote:

> In D68115#1946990 <https://reviews.llvm.org/D68115#1946990>, @jfb wrote:
>
> > In D68115#1946757 <https://reviews.llvm.org/D68115#1946757>, @rsmith wrote:
> >
> > > In D68115#1946668 <https://reviews.llvm.org/D68115#1946668>, 
> > > @hubert.reinterpretcast wrote:
> > >
> > > > It sounds like we are looking for `-fzero-union-padding`. That's been 
> > > > where the discussion has left off twice for months.
> > >
> > >
> > > I believe the state of Clang prior to this patch is actually wrong.
> >
> >
> > That's my understanding as well. I'd like it if this patch (or a follow-up) 
> > got us back to standard behavior. In either case, I'd like the proposed 
> > behavior to bee on-by-default when doing initialization of stack variables.
>
>
> Your preference is noted. However, I think the majority opinion expressed on 
> this review at this point favors not guaranteeing zero-initialization except 
> where required by the relevant standard. That'd also be consistent with our 
> stance on trivial auto variable initialization in general.


Sorry, I didn't express myself well: if trivial auto-var init is on, then I 
want initialization of union padding to also be on. I think this is exactly 
compatible with what you want, as is says nothing of the behavior when trivial 
auto-var init is not on.

> I'm not yet sure about whether we want separate controls for this and for 
> `-ftrivial-auto-init`, or whether from a user's perspective there's really 
> only one question: should bits left uninitialized be `undef`, guaranteed 
> zero, or guaranteed to be filled with a pattern -- independent of whether 
> they're padding bits? (And related, do we actually want control over zeroing 
> union padding in all cases or only for trivial automatic variables? And do we 
> want control over zeroing or pattern-filling objects allocated with `new` 
> with trivial initialization?)

Trivial auto-var init should always initialize all stack padding, and should 
not also initialize heap padding. There should be separate controls for heap 
padding, in part because this interacts with the allocator (whereas stack 
initialization does not).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to