<div dir="ltr">On Mon, May 1, 2017 at 7:06 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(80,0,80)">On Mon, May 1, 2017 at 3:58 PM, John McCall </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_1877409448881427319h5"><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"><span class="m_1877409448881427319m_811507590662182002gmail-">On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class="m_1877409448881427319m_811507590662182002gmail-"><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, May 1, 2017 at 3:09 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><span><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, May 1, 2017 at 2:07 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><span><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><div class="m_1877409448881427319m_811507590662182002gmail-m_-2450567185769507685m_-4811635330834390567m_-7259718727137271957h5">On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_1877409448881427319m_811507590662182002gmail-m_-2450567185769507685m_-4811635330834390567m_-7259718727137271957h5"><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_extra"><div class="gmail_quote"><span><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_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">So you believe that you can index into an object randomly by pointer arithmetic and pull out a different field?<br></div></blockquote></span><div><br></div><div>For starters, this is  illegal because you don't know where the padding bytes are.</div><div>You cannot assume that X.a + 1 == X.b</div><div>"Implementation alignment requirements might
cause two adjacent members not to be allocated immediately after each other;"</div><div><br></div><div>See 9.2.14</div></div></div></div></blockquote><div><br></div></span><div>IE at best you'd have to add</div><div><br></div><div> &(struct X*(0))->b - &(struct X*(0))->a</div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't believe this is legal either.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let me try to dredge up the long discussions we had about these cases on the gcc mailing lists.</div><div class="gmail_extra">The conclusion was, i believe:</div><div class="gmail_extra"><br></div><div class="gmail_extra">"if you want to go marching through an object as a char *, that's fine, if you expect to be able to get at fields by playing pointer arithmetic games, from other fields, that is not)</div><div class="gmail_extra">I feel like every couple years, a different compiler has the same aliasing discussions :)</div></div></blockquote><div><br></div></div></div><div>With the caveat that, in practice, compilers have to support both:</div><div>  a) "going up a level" by subtracting an offsetof, which is clearly officially intended and not otherwise supported,</div></div></div></div></blockquote><div><br></div></span><div>AFAIK, Vtable accesses were supported by doing this, but pretty much nothing else.</div></div></div></div></blockquote><div><br></div></span><div>and to be clear, i mean given:<br><br></div><div>struct a</div><div>{ </div><div>int a;</div><div> struct b bstruct;</div><div>}; </div><div><br></div><div>given a pointer to bstruct, subtracting sizeof(int)  is not going to give you a pointer to a struct a.</div></div></div></div></blockquote><div><br></div></span><div>If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure should (if you're doing the pointer arithmetic on an appropriate type, of course).</div><span class="m_1877409448881427319m_811507590662182002gmail-"><div><br></div></span></div></div></div></blockquote><div> </div><div><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_extra"><div class="gmail_quote"><span class="m_1877409448881427319m_811507590662182002gmail-"><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_extra"><div class="gmail_quote"><div>It was allowed to work for vtable accesses.</div></div></div></div></blockquote><div><br></div></span><div>I would like to once again remind you that random mailing list conversations you happened to be in but can't even remember from some completely unnamed</div></div></div></div></blockquote><div><br></div></div></div><div>It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.</div><div>I can even give you approximate dates if you like.</div><div><br></div><div>I don't believe calling "the other major compiler's mailing list", which treaded exactly this topic, is "a random mailing list conversation", or "an unnamed source" or a "different context" </div></div></div></div></blockquote><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><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_extra"><div class="gmail_quote"><div>and possibly different context are neither authoritative nor binding on us now. :)</div><span class="m_1877409448881427319m_811507590662182002gmail-HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote></span><div>John, while i appreciate the smiley, this is kind of rude.</div><div>Without a good reason to be different, we should follow the paths other compilers have taken and users have become used to. Both in what we allow, and what we disallow.</div><div>So if the plan here is go off and do something that is going to be completely different than what users expect from their compilers, that doesn't make a lot of sense to me.</div><div>Otherwise, if you really don't want me to tell you what they've done, and try to explain why, okay, fine, then i'll bow out of these discussion and leave y'all to do whatever.</div><div><br></div><div>Just don't expect me to okay patches to llvm that implement the current kind of hacks we currently have.</div></div></div></div></blockquote><div> </div><div>Daniel, I have a huge amount of respect for the GCC developers and the work that they've done, and I'm very interested in hearing what they thought.  If you're willing to present their discussions as prior art and as input that we should consider in determining Clang's optimization strategy, I think that would be extremely valuable.  But no, it is not appropriate to treat those conversations as a sort of binding precedent that can only be over-ruled with great force; it is completely reasonable for us to discuss these things and come to different conclusions about both the meaning of the standard and the proper design of an optimizer.</div><div><br></div><div>In particular, GCC has a history — of which this is an instance — of coming up with a remarkably strict reading of the standard and then telling anybody who complains to pass a flag to just disable the optimization.  To my mind, that is not a reasonable way to design an optimizer, especially when, frankly, that original reading seems pretty questionable and it seems plausible that a weaker interpretation would still provide almost all of the real optimization value.</div><div><br></div><div>In this case, it seems to me that the vast majority of the power of a language rule that says that you cannot alias one field from a pointer to another comes from forbidding out-of-bounds member array accesses from reaching into earlier or later fields.  Such accesses will overwhelmingly arise from member access expressions, not explicit pointer arithmetic on char*; meanwhile, there are known idioms for pointer arithmetic on char* that do not have any apparent replacement under a stronger rule.  In situations like this, I think the burden lies on the designer of the optimization to prove that it's both worth taking away a feature and that there's no effective alternative.</div><div><br></div><div>John.</div></div>
</div></div>