<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 August 2017 at 12:24, Paul Robinson via Phabricator via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">probinson added a comment.<br>
<br>
Locally we have a couple different tactics for dealing with changes that we can't support.  A more coherent approach would be great.<br>
For example we defined a new TargetCXXABI::Kind value that is mostly GenericItaniumABI except where it isn't.<br>
I personally did not do most of the various ABI-related tweaks so I don't claim to have a good handle on them, and we have been slow to get these things upstream; but I'd love to make that happen.</blockquote><div><br></div><div>I'm looking into adding a more general mechanism to request ABI (bug) compatibility with a prior version of Clang.</div><div><br></div><div>Paul: is the PS4 toolchain's ABI based on that of a particular Clang release, or is it a branch from trunk at some point? Or something else? (And which release / revision?)</div><div><br></div><div>John: X86_64ABIInfo::classifyIntegerMMXAsSSE() has a special case for Darwin OSes for compatibility with older Clang compilers; likewise for X86_64ABIInfo::honorsRevision0_98(). Is this a case of wanting compatibility with an older version of Clang by default when targeting Darwin, or is it just the case that the platform ABI is different for that target (where the historical reason for the different choice in the platform ABI was a bug in older versions of Clang)?</div></div></div></div>