<div dir="ltr">On Wed, Sep 11, 2013 at 11:38 AM, Nico Rieck <span dir="ltr"><<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</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 class="im">On 09.09.2013 18:36, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How's this patch doing?  It's come up on the mailing lists a few times, so I thought I'd ping. :)<br>
</blockquote>
<br></div>
I guess it's mainly lacking more feedback about which variant to pursue. As reasoned before, I don't really like conflating the term "visibility" with dllimport (it would also require making -fvisibility=hidden the default). But opinions on this have been very scarce.<br>

</blockquote></div><br></div><div class="gmail_extra">As for opinions, everyone I talked to locally felt that if the export controls can't be combined with visibility, then there's no reason to make the invalid combinations representable in IR.  Maybe they'll chime in.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I don't see a need to make -fvisibility=hidden the default, either.  I don't want to use the same enum for default visibility and dllexport.  It seems to me that default visibility should be the platform default visibility when linking DSOs, and dllexport should force a symbol into .drectve and possibly into .dynsym for ELF, if that's representable in a .o file.</div>
</div>