<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 8:46 AM, 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>I *think the argument* goes that this is a 20 or 24 byte object, so if you *could* put something of type PB at c-8, you'd illegally overlap with the object at c.</div><div><br></div><div>Thus, there can't be an object of type PB at c-8.</div><div><br></div><div>(IE any valid object must be sizeof(PB) away in either direction, which means it's not possible for c->f1_ to clobber c no matter what bar does)</div></div></blockquote><div><br></div><div>Ah, I'm not sure just how loose no-strict-aliasing is, I figured that would allow overlapping objects, etc? (if it allows treating memory as both an int and a float, etc, I wouldn't've guessed it would disallow accessing part of it as one, part as another, etc - so long as alignment was preserved) seemed to me like that was the point, but, yeah, I really don't know much about it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div><br></div><div><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 8:24 AM, David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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">Why would computing that pointer be invalid?<br><br>(I could imagine, if there was no object behind c to point to it would be invalid - but that's a dynamic property of the program that the compiler, given this code, can't prove /isn't true/ (the programmer might've constructed the caller such that it does always have an object behind 'c' to point to))</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 18, 2016 at 1:28 AM, Markus Trippelsdorf via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 2016.03.17 at 16:35 -0700, Chris Lattner via llvm-dev wrote:<br>
><br>
> > On Mar 15, 2016, at 7:58 AM, Chuang-Yu Cheng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Please look at this c code:<br>
> ><br>
> > typedef struct _PB {<br>
> >   void* data;  /* required.*/<br>
> >   int   f1_;<br>
> >   float f2_;<br>
> > } PB;<br>
> ><br>
> > PB** bar(PB** t);<br>
> ><br>
> > void qux(PB* c) {<br>
> >   bar(&c);              /* c is escaped because of bar */<br>
> >   c->f1_ = 0;<br>
> >   c->f2_ = 0.f;<br>
> > }<br>
> ><br>
> > // gcc-5.2.1 with -fno-strict-aliasing -O2 on x86<br>
> > call    bar<br>
> > movq    8(%rsp), %rax<br>
> > movl    $0, 8(%rax)<br>
> > movl    $0x00000000, 12(%rax)<br>
> ><br>
> > // llvm 3.9.0 with -fno-strict-aliasing -O2 on x86<br>
> > callq    bar<br>
> > movq    (%rsp), %rax<br>
> > movl    $0, 8(%rax)<br>
> > movq    (%rsp), %rax<br>
> > movl    $0, 12(%rax)<br>
> ><br>
> > You can see that llvm load "c" twice, but gcc only load "c" once.<br>
> > Of course, in bar function, you may do something very dangerous, e.g.<br>
> ><br>
> > PB** bar(PB** t) {<br>
> >    *t = (PB*) t;<br>
> > }<br>
> ><br>
> > But gcc doesn't care bar's definition.<br>
> > Is llvm too conservative, or gcc too aggressive in this pattern?<br>
><br>
> In my opinion, in the face of -fno-strict-aliasing, GCC is being too<br>
> aggressive.  It would be interesting to hear what they think.<br>
<br>
</div></div>We discussed this issue briefly on the #gcc IRC channel.<br>
Richard Biener pointed out that bar cannot make c point to &c - 8,<br>
because computing that pointer would be invalid. So c->f1_ cannot<br>
clobber c itself.<br>
<span><font color="#888888"><br>
--<br>
Markus<br>
</font></span><div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br></div></div>