<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 11:55 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">[..]<div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>In theory, the last time i remember, you weren't allow to set one member of a union and read another.</div><div>But uh, that's not real user code :)</div><div><br></div><div>(and IIRC, it does not say anything real)</div><span class=""><div> <br></div></span></div></div></div></blockquote><div>This is indeed correct. The main issue is that llvm thinks it is allowed to reorder 'stores' (as it thinks they are not aliasing),<br>so that a legal read afterwards will result in a wrong answer (if an optimization or the backend reorders the stores based on the wrong aliasing information).<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If you access a member (or nested member) of a union, starting from the union itself, then it depends if the other type is also accessible through the union.<br><br><br></div><div>So:<br><br></div><div>int foo(union foo* a, float* b, int* c) {<br></div><div>  a->a=1;<br></div><div>  *b=2;<br></div><div>  // compiler must assume a->a and *b can alias<br></div><div>  // compiler must not assume *b and *c alias (access not through union)<br></div><div>}<br><br></div><div>(Also see section 3.10 of the c++03 standard;</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>This, IMHO, does not say what you seem to think it does :)</div><div><br></div><div>For C++03,  3.10 only includes the word "union" here: "If a program attempts to access the stored value of an object through an lvalue of other than one of the following
types the behavior is undefined: </div><div><br></div><div>— the dynamic type of the object, </div><div>— a cv-qualified version of the dynamic type of the object, </div><div>— a type that is the signed or unsigned type corresponding to the dynamic type of the object,</div><div> — a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of
the object, </div><div>— an aggregate or union type that includes one of the aforementioned types among its members (including,
recursively, a member of a subaggregate or contained union),</div><div> — a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,</div><div> — a char or unsigned char type."<br><div><br><br></div><div>C++ standard experts, at least on the GCC side, did not view this as saying "all accesses must have an explicit union access", but that "It must be part of a union type", but about whether you try to access it through a union that doesn't have the right actual types in it.</div></div><div><br></div><div>The type of those objects is right the type of the object. There is, IMHO,  nothing illegal about those accesses.</div><div><br></div><div><br></div></div></div></div></blockquote><div><br>So, with that interpretation, the mere presence of a 'union { short s; int i; }' (in the same or a different compilation unit) should influence the (type based) aliasing of all short and int pointers ?<br></div><div>This doesn't look a practical solution to me :(<br></div><div></div><div>That's why I settled on the need of having the full access path available as a practical solution (and one that can easily be explained)..<br></div><div><br></div><div>(btw. Do you have a pointer to the discussion on the gcc side ?)<br><br></div><div>What we currently have is definitely wrong. Question is how we want to fix it...<br><br></div><div>Greetings,<br><br></div><div>Jeroen Dobbelaere<br><br></div></div></div></div>