<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 January 2015 at 03:25, 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 class="">> On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">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></blockquote><div><br></div><div>Not sure if that is viable fight on our side, but we can try making it an error and see.</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">
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.</blockquote><div><br></div><div>So, the case in pr16187 is one where I think there is no question that our answer is worse than gcc's. The *same* type shows up as both hidden and default. If this was a new language we were designing, it is hard to imagine a worse compromise.</div><div><br></div><div>The reason we got there is that we tried and failed to enforce a stricter models. First one that says that we can compute the type early and then one that says we can compute it on first "use". Both have failed to build real world software, which IMHO is a fundamental requirement for clang.</div><div><br></div><div>The case of "typedef struct {...} foo;" doesn't look as widespread, but it is unfortunately a core part of the language (not a gcc extension) that we cannot currently implement.</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">  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.</blockquote><div><br></div><div>An interesting language design advice, but given the requirement that clang continues to build real c++ code, it is important to ask if we are not pushing ourselves to solutions that are worse than what gcc does (which I am sure is the case in pr16187).</div><div><br></div><div>Cheers,</div><div>Rafael</div><div><br></div></div></div></div>