<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 15, 2014 at 1:38 PM, Yunzhong Gao <span dir="ltr"><<a href="mailto:Yunzhong_Gao@playstation.sony.com" target="_blank">Yunzhong_Gao@playstation.sony.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"><div class="">> Reid pointed out that we would get the linkage wrong for exported functions in C99 mode, and that the reasonable thing to do would be to use MS semantics dllimport/export inline functions. I'll update the patch to do this.<br>

<br>
</div>@rnk. If I recall correctly, Microsoft does not support C99 inline. What does MinGw(64) do in this case?<br></blockquote><div><br></div><div>They don't.  They follow something similar to C++ inline semantics in C, with the extra caveat that an 'extern' redeclaration of an inline function will force it to be emitted.  Either way, with or without 'extern', any code for the function is comdat deduplicated with other instances of the same function.</div>
<div><br></div><div>MinGW64 GCC basically treats dllexport as something that implies an extern storage class.  This produces a strong external definition of foo:</div><div><div>inline __attribute__((dllexport)) void foo() {}</div>
</div><div><br></div><div>Things are simple for dllimport, because C99 inline already uses available_externally linkage.</div></div></div></div>