<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2015, at 9:25 AM, David Majnemer <<a href="mailto:david.majnemer@gmail.com" class="">david.majnemer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 12:25 AM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><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 class="">> On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="">rafael.espindola@gmail.com</a>> wrote:<br class="">
><br class="">
> Sent the email a bit early.<br class="">
><br class="">
><br class="">
>>> That is not what I am seeing with gcc. Given<br class="">
>>><br class="">
>>> int pr22217_foo;<br class="">
>>> int *b = &pr22217_foo;<br class="">
>>> extern int pr22217_foo __attribute__((section("zed")));<br class="">
<br class="">
</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 class="">
<br class="">
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 class=""></blockquote><div class=""><br class=""></div><div class="">Some of my argument against eagerly emitting IR comes stems from how we handle the following:</div><div class=""><div class="">struct S;</div><div class=""><br class=""></div><div class="">typedef void (*FP)(struct S);</div><div class=""><br class=""></div><div class="">void f(FP x) { }</div><div class=""><br class=""></div><div class="">struct S { int i; };</div><div class=""><br class=""></div><div class="">void g() { f(0); }</div></div><div class=""><br class=""></div><div class="">When we are emitting f, we decide that FP should have IR type {}*.</div><div class="">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 class=""><br class=""></div><div class="">The fact that types change from under us is very surprising.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div></div>Global values changing types is, unfortunately, inevitable, because it is not currently possible to give a global variable an arbitrary IR type when it has a constant initializer, and global variables can have references to each other, even cyclically. It is not actually difficult to deal with; it's good practice to hold persistent references with a value handle anyway.<div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">John.</div></div></div></div></body></html>