<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 12:25 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><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"><span>> On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
> Sent the email a bit early.<br>
><br>
><br>
>>> That is not what I am seeing with gcc. Given<br>
>>><br>
>>> int pr22217_foo;<br>
>>> int *b = &pr22217_foo;<br>
>>> extern int pr22217_foo __attribute__((section("zed")));<br>
<br>
</span>This should be an error in both C and C++.  I see absolutely no reason to allow a declaration following a definition (even a tentative definition) to add a section attribute.  We should not be afraid to reject stupidly-written code when it abuses language extensions, even when they’re not “our” extensions.<br>
<br>
There are fair arguments against our current emit-as-you-go IRGen model, but allowing us to more perfectly emulate GCC’s bugs is not one of them.  Nor is there a need to exactly copy GCC’s visibility model in every conceivable case.  One very nice incidental advantage of emit-as-you-go is that it encourages us to ensure that language decisions are made locally by the declarations involved, which — beyond simply being better language design in and of itself — also means that they’re not susceptible to random breakage by differences in module import.<br></blockquote><div><br></div><div>Some of my argument against eagerly emitting IR comes stems from how we handle the following:</div><div><div>struct S;</div><div><br></div><div>typedef void (*FP)(struct S);</div><div><br></div><div>void f(FP x) { }</div><div><br></div><div>struct S { int i; };</div><div><br></div><div>void g() { f(0); }</div></div><div><br></div><div>When we are emitting f, we decide that FP should have IR type {}*.</div><div>However, the definition of 'S' is available when we are emitting 'g' and so we decide that FP have IR type void (i32)*.</div><div><br></div><div>The fact that types change from under us is very surprising.<br></div><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">
<span><font color="#888888"><br>
John.</font></span></blockquote></div><br></div></div>