<div dir="ltr">I do hope that the intent is not to ensure that clang has bug-for-bug compatibility with earlier versions.  We've fixed many bugs over time which would necessitate ABI breaks from earlier versions of clang.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 9:11 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">----- Original Message -----<br>
> From: "Sean Silva" <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>><br>
> To: "Sunil Srivastava" <<a href="mailto:sunil_srivastava@playstation.sony.com">sunil_srivastava@playstation.sony.com</a>><br>
> Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> Sent: Wednesday, July 2, 2014 10:58:18 PM<br>
> Subject: Re: [cfe-dev] Proposal for an ABI testsuite for clang<br>
><br>
><br>
><br>
><br>
> Since the goal is compatibility with a previous version, why does the<br>
> test suite itself contain the "right answers" that it checks<br>
> against? Shouldn't the "right answers" be determined by a "golden<br>
> master" version of the toolchain?<br>
><br>
><br>
><br>
> Roughly what I'm saying is instead of "check(..., expected)" instead<br>
> do "print(...)". Then compare what is printed with the output<br>
> produced by the program when compiled with the reference toolchain.<br>
> This approach seems more useful, since:<br>
><br>
><br>
> a) it tests what we actually care about, which is that the code is<br>
> compatible with a reference toolchain. At the end of the day,<br>
> compatibility with existing compiled code is more important than<br>
> actually sticking to the ABI specification.<br>
<br>
</div>I understand why you say this, and comparing to a reference toolchain is also valuable, but having checks against the ABI specification itself is independently valuable. This is especially true when the Clang/LLVM toolchain *is* the vendor-provided reference toolchain. I support testing both modes, but I really like the testing-against-the-ABI-spec aspect of what was proposed. This would be a unique contribution to open-source compiler development in general, let alone LLVM.<br>

<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> b) it lets you use whatever baseline you want. E.g. possibly some<br>
> internal toolchain that unfortunately shipped with a bug; or the<br>
> MSVC toolchain, which would be immediately useful for the folks<br>
> working on MS ABI compatibility. In fact, this test suite could<br>
> easily be used to create an instant checklist of incompatibilities<br>
> between *any* two compilers that claim to be compatible (not even<br>
> from the same vendor).<br>
><br>
><br>
> c) Allows expansion to any other target or ABI by simply expanding<br>
> the set of "every possible ..." to cover any extra details relevant<br>
> to the new target or ABI. Hence the test suite is naturally target<br>
> and ABI agnostic. Adding new checks for a different ABI<br>
> automatically strengthens the checks for all ABI's.<br>
><br>
><br>
> As an example of c), consider the following: Suppose that to extend<br>
> the test suite to MS ABI, you find that you need to generate a new<br>
> code construct that exercises a particular aspect of the MS mangling<br>
> which the existing Itanium cases didn't cover. If you compile this<br>
> construct with two different Itanium ABI compilers and the mangled<br>
> names differ, then that is an incompatibility.<br>
><br>
><br>
> In this sense, I think the goal of the ABI compatibility test suite<br>
> should be to collect/generate source code constructs that exercise a<br>
> particular dimension along which two C++ compilers could have an ABI<br>
> incompatibility. This is mostly agnostic to the target or the<br>
> compiler being used (a small amount of stuff would need some target<br>
> hooks, like getting a mangled symbol name, but the bulk should be<br>
> portable and platform agnostic).<br>
><br>
><br>
> I think that what you guys have already done (the steps you list<br>
> under "A set of ‘interesting’ classes for the test-suite is<br>
> generated by:") is excellent progress in this direction of<br>
> collecting examples that exercise dimensions of potential<br>
> incompatibility since by construction the Itanium ABI (or any ABI<br>
> spec) tries to cover all the relevant dimensions which could cause<br>
> an ABI incompatibility.<br>
><br>
><br>
> -- Sean Silva<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Wed, Jul 2, 2014 at 4:51 PM, Srivastava, Sunil <<br>
> <a href="mailto:sunil_srivastava@playstation.sony.com">sunil_srivastava@playstation.sony.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
><br>
> Hi,<br>
><br>
> At the SN Systems division of Sony, we have developed an IA64 ABI<br>
> test-suite for clang/llvm based on the lit framework. We would like<br>
> to submit this to the LLVM community. The test-suite currently<br>
> supports clang in both LP64/x86-64 and ILP32/x86 targets, with the<br>
> ability of adding others. The tests perform target-side execution<br>
> and work with both cross and native targets.<br>
><br>
> Please find attached a pdf document that describes the design of this<br>
> test-suite. In summary, the test-suite covers:<br>
> · struct layout rules, including bit-fields,<br>
> · Object layout, base classes, vtables, VTTs, construction vtables,<br>
> · Name mangling,<br>
> · Contents of typeinfo variables,<br>
> · Array cookies,<br>
> · and a few other items.<br>
><br>
> Please consider accepting this test-suite as an llvm project. We look<br>
> forward to addressing any comments and questions you have on this<br>
> topic.<br>
><br>
> Best regards,<br>
><br>
><br>
><br>
> Sunil Srivastava<br>
><br>
> SN Systems / Sony Computer Entertainment<br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</div></div><div class="im HOEnZb">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>