<div dir="ltr">On Thu, Mar 28, 2013 at 8:59 AM, Joe Groff <span dir="ltr"><<a href="mailto:arcata@gmail.com" target="_blank">arcata@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 dir="ltr"><div class="im">On Thu, Mar 28, 2013 at 8:55 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <span dir="ltr"><<a href="mailto:arcata@gmail.com" target="_blank">arcata@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><span style="color:rgb(80,0,80)">On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>



</div><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(34,34,34)">This is why I suggest that the Windows ABI is whatever MSVC happens to do. The mingw ABI happens to consist of a conjunction of what MSVC does for C and what GCC on Linux does for C++. That is a unique and different ABI, and I don't think you can reasonably call it *just* "windows" at any point.</span><br>




</div><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888">
<div><br></div></font></span></div></div></div></blockquote></div></div><div>This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the C level—for instance, alignment of pass-by-value structs sometimes differs, and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw. There are other differences too.</div>


</div></div></div></div></div></blockquote><div><br></div></div></div><div>Can you clarify what you mean by the "sret pointer is callee-cleanup" vs caller-cleanup?</div></div></div></div></blockquote><div><br></div>

</div><div>In the epilog for a function with an indirect struct return argument, MSVC emits a 'ret 4' to pop the return pointer argument. Mingw emits a 'ret'.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What we were specifically hitting yesterday was that MSVC expects the sret pointer passed into also be returned in eax.  LLVM already does this for x86_64 everywhere.  Mingw doesn't do this, but I think it was just a coincidence.  This behavior was undocumented, and that there was probably no OS API takes a callback which returns a struct larger than 8 bytes.</div>


<div><br>This makes me think that it would be better if we started returning the sret pointer from such functions under Mingw for improved compatibility at the C ABI level.  This shouldn't break any mingw code so far as I can tell.  It seems reasonable for a user to expect that the Mingw and Microsoft C ABIs be compatible, but maybe there are enough other corner cases that this is just naive.</div>


</div></div></div>
</blockquote></div></div><br></div><div class="gmail_extra">Good catch. Returning the sret pointer in eax shouldn't affect Mingw compatibility since EAX isn't preserved across calls in either the Microsoft or Mingw ABIs (IIRC).</div>
</div></blockquote><div><br></div><div style>Yeah, but the ret / ret 4 discrepancy means they're still fundamentally incompatible, so this wouldn't help.  =/ </div><div></div></div></div></div>