<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 22, 2016, at 12:06, Bryan Chan via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><tt class=""><a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a> wrote on 2016-03-22 02:37:47 PM:<br class=""><br class="">> The runtime functions are hacked in various unsavory ways to give <br class="">> them Swift-like calling conventions. Many of them also have <br class="">> important semantics that the compiler needs to be aware of, so if <br class="">> they aren't exported as standard library API in some way, you really<br class="">> shouldn't interact with them directly. <br class="">> (swift_class_getInstanceExtents happens to be OK, but what are you <br class="">> trying to do with it?)</tt><br class=""><br class=""><tt class="">I am trying to build Swift on a different architecture (s390x). This</tt><br class=""><tt class="">function was causing crashes due to the ABI mismatch, and I also</tt><br class=""><tt class="">found that the issue is not 100% fixed on x86 either, so I wondered</tt><br class=""><tt class="">if the community has an opinion on the right way to deal with this</tt><br class=""><tt class="">in the runtime, or if the answer is simply "don't do this for</tt><br class=""><tt class="">3-scalar returns".</tt><br class=""></p></div></div></blockquote></div><br class=""><div class="">To be clear, @_silgen_name is <i class="">unsupported</i> for general use (generally true of anything that starts with an underscore). We use it in the standard library for certain things that can't be expressed in C, but there are plenty of places that <i class="">can</i> be expressed in C that maybe should be using the SwiftShims headers instead. We use it in tests because of laziness. You should really not use it for production code.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></body></html>