<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 3, 2014 at 2:41 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</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="">On 3 July 2014 06:02, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<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>
>> I understand why you say this, and comparing to a reference toolchain is<br>
>> also valuable, but having checks against the ABI specification itself is<br>
>> independently valuable. This is especially true when the Clang/LLVM<br>
>> toolchain *is* the vendor-provided reference toolchain. I support testing<br>
>> both modes, but I really like the testing-against-the-ABI-spec aspect of<br>
>> what was proposed. This would be a unique contribution to open-source<br>
>> compiler development in general, let alone LLVM.<br>
><br>
><br>
> The two things aren't mutually exclusive. If you want to check against the<br>
> spec with the approach I suggested, then just generate an output file which<br>
> is what you think is correct according to the spec and use that as a<br>
> baseline (instead of generating the baseline output file by compiling the<br>
> code in the test suite with a reference compiler).<br>
<br>
</div>Sean,<br>
<br>
I have to strongly disagree with you up there. Testing the ABI is more<br>
important than testing compatibility with other compilers.</blockquote><div><br></div><div>They are both important. My suggestion addresses both of them (see below). Think of my suggestion as a primitive that can be used for both purposes (see at the end of this post also).</div>
<div><br></div><div>However, in the OP's PDF, it says that what actually motivated this work is consistency with previous compilers: "In some industries, *consistency is more important than correctness*. Hence the need for a test-suite to *guard against changes*." (emphasis mine)</div>
<div>I am not involved with this project internally at Sony, but I know that an extremely important use case for our clients is binary-only libraries. Hence ensuring ABI compatibility with previous platform compilers is important.</div>
<div><br></div><div>The ability to use a "spec" baseline or a "golden master" baseline by just swapping the baseline file is key to reconciling the two conflicting desires:</div><div>1. the open source project wants to be as "by-the-spec" ABI-compliant as possible</div>
<div>2. maintainers of platform compilers want to ensure that their platform compilers are compatible with previous code compiled for the platform.</div><div><br></div><div>Since it seems that #2 is the thing that actually motivated this work, I think it is important to take that into account.</div>
<div><br></div><div>Also keep in mind that the test-suite generator program that generates the "right answers by the spec" is also subject to human fallibility in the same way as the the ABI code and tests inside clang itself (although the narrower focus of the generator might reduce the chance of error). The extent to which this test suite actually provides an independent check on Clang's ABI correctness depends on how it was developed; I would be interested to know:</div>
<div><br></div><div>- how many times during the development of this test suite clang's behavior diverged from the "expected" behavior as computed by the generator program, and the generator program was later found to be in error.</div>
<div><br></div><div>- (less likely) how many times the generator program produced a test that happened to align with a "by-the-spec incorrect" bug in clang, and the agreement was interpreted as both being correct. (we can't really know this number, of course)</div>
<div><br></div><div>- what would happen if this test suite does indeed find a bug with a previous reference toolchain? Would that necessitate an internal fork of the test suite that has a deliberately "incorrect" (by the spec) test?</div>
<div><br></div><div>I think that checking against another independently developed compiler targeting the same ABI will provide at least as much of an independent check on Clang's correctness as a written-from-scratch generator program, if not moreso. Of course, checking two compilers against a generator transitively gives you that benefit, but is less accommodating of the requirement of checking actual code compatibility against a given baseline (that may have a bug; and would you bet that it doesn't?).</div>
<div> </div><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"> IF the<br>
other compiler doesn't follow the ABI, it should be fixed, that's a no<br>
brainer, and any decent compiler community will not argue against ABI<br>
breakages. Testing against other compilers is *also* important, but<br>
not to the detriment of ABI checking.<br>
<br>
Also, checking the ABI against expected results make it explicit, and<br>
helps a lot on debugging problems when they happen. An expected output<br>
can have comments pointing out the ABI paragraph and document, as well<br>
as having some regular expression / pattern matching structure that<br>
"explains" the document in a programming-friendly way.</blockquote><div><br></div><div>I don't think that what you are asking for is mutually exclusive with what I'm suggesting. I think you're imagining the baseline output as just a flat file containing a bunch of meaningless numbers printed in it. Realistically each item printed in the output file would likely be keyed on a unique identifier of some sort, and it would simply be a matter of going to the place in the test file that contains that unique identifier. The citation comments that you are suggesting could reside on the source code in exactly the way you suggest. I'm not sure what you mean by '"explains" the document in a programming-friendly way' so I can't comment on that.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><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"> This is<br>

invaluable, and we don't normally have that because people don't<br>
normally have time to write it. If someone did this, we should not<br>
discard and request a poorer check.<br>
<br>
But checking against another compiler using patterns and documentation<br>
won't work, because there isn't any, just the good old diff. In that<br>
case, I agree, diffing against a golden standard is the way to go, and<br>
I also agree we should have that *in addition* to ABI tests.<br>
<br>
My tuppence.<br>
<span class=""><font color="#888888"><br>
--renato<br>
</font></span></blockquote></div><br></div></div>