<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 26, 2019 at 10:28 PM Vitaly Buka <<a href="mailto:vitalybuka@google.com">vitalybuka@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><a href="https://reviews.llvm.org/D68115" target="_blank">https://reviews.llvm.org/D68115</a><br><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 24, 2019 at 9:09 PM Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">On Mon, Sep 23, 2019 at 5:36 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Hi Vitaly,</div><div><br></div>Indeed: there are cases where clang happened to honor the standard without intending to (through the magic of memcpy’ing globals), and auto-init=pattern broke this. I got a report about it a while ago and agree it’s an issue, I haven’t had time to fix it. It’s related to what C calls “designated initializers” to initialize structs. The relevant standardese from C17 are in 6.7.9 Initialization (the grammar has “designator” being either “ [ constant-expression ] ” or “ . identifier ”).<div><br>The relevant rules are:<br><br>“””<br>Except where explicitly stated otherwise, for the purposes of this subclause unnamed members of objects of structure and union type do not participate in initialization. Unnamed members of structure objects have indeterminate value even after initialization.<br><br>If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, then:<br>— if it has pointer type, it is initialized to a null pointer;<br>— if it has arithmetic type, it is initialized to (positive or unsigned) zero;<br>— if it is an aggregate, every member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;<br>— if it is a union, the first named member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;<br><br>The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.<br><br>If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.<br>“””<br></div></div></blockquote><div>Unions are not aggregates in the C standard, so the last sentence does not apply.<br></div><div> </div></div></div></blockquote><div>I assume it's not going to hurt if we zero init there? I see a lot of code which assume that large fields will be initialized, and not sure how to use non-zero behaviour.</div></div></div></blockquote><div>There are still platforms where such code breaks naturally anyway because the zero value for a particular type is not the same as having zeroes for all the bytes of its object representation. Under the status quo, <span style="font-family:monospace">-ftrivial-auto-var-init</span> has some ability to act as a tool for portability. Although, as noted in this thread, the status quo is neither here nor there with actually using the pattern (or using zeroes or something else).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br>I had fixed something in <a href="https://reviews.llvm.org/D61280" target="_blank">https://reviews.llvm.org/D61280</a> but it’s not sufficient.</div><div><br></div><div><br></div><div>I don’t think fixing this is giving up: it’s doing what the standard mandates.</div><div><br></div><div>Are you interested in fixing it?</div><div><br><div><br></div><div><br><blockquote type="cite"><div>On Sep 23, 2019, at 2:20 PM, Vitaly Buka <<a href="mailto:vitalybuka@google.com" target="_blank">vitalybuka@google.com</a>> wrote:</div><br><div><div dir="ltr"><div style="background-color:rgb(255,255,254)"><div>Hi everyone,</div><div><br></div><div>I am trying to enable -ftrivial-auto-var-init=pattern on various code and noticed inconvenient inconsistency with code like [1].</div><div><br></div><div>According standard, as I understand, only the first member of the union must be initialized and the tail of the second member can stay uninitialized. If we use -ftrivial-auto-var-init=pattern it fills the tail using our pattern. However by default GCC, clang (without -ftrivial-auto-var-init), msvc all initialize entire union with 0s. Not sure if it's just coincidence or guaranteed feature.</div><div><br>So -ftrivial-auto-var-init=pattern breaks such code. Especially bad if you don't know that U is a union and ={} looks good there.<br></div><div><br></div><div>Should we consider giving up here and using zeroes for union tails even with -ftrivial-auto-var-init=pattern?</div><div><br></div><div>1. Example:<br></div><div><span style="color:rgb(0,0,255)">union</span> U {</div><div> <span style="color:rgb(0,0,255)"> char</span> small[<span style="color:rgb(9,136,90)">2</span>];</div><div> <span style="color:rgb(0,0,255)"> char</span> large[<span style="color:rgb(9,136,90)">100</span>]; </div><div>};</div><div><span style="color:rgb(0,0,255)">void</span> f(<span style="color:rgb(0,0,255)">void</span>*);</div><div><span style="color:rgb(0,0,255)">void</span> test() {<br></div><div> <span style="color:rgb(0,0,255)"> union</span> U u = {};</div><div> f(&u);</div><div>}<br></div></div></div>
</div></blockquote></div><br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>