Just to also reply to Renato's concerns here, I'm on the same page with David here.<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 8:41 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Dec 3, 2012 at 1:37 AM, Renato Golin <<a href="mailto:rengolin@systemcall.org">rengolin@systemcall.org</a>> wrote:<br>

> Apart from what has already being said, which I agree mostly, I have<br>
> some specific comments:<br>
><br>
><br>
>> a. We change the test suite to run in such a way that all tools default to<br>
>> an "unknown" host triple.<br>
><br>
> The assumptions will be different and I believe the refactoring of the<br>
> tests to make them pass on all currently passing architectures will<br>
> not be trivial. Good luck! ;)<br>
<br>
</div>I'm not sure what you mean by "refactoring of the tests to make them<br>
pass on all currently passing architectures" - if we force tests<br>
without specified triples to use an "unknown" triple, the tests would<br>
need to be refactored, but why would they need to be refactored to<br>
account for all currently passing architectures? They should behave<br>
exactly the same (since they won't inherit the host triple that they<br>
do now) on all test machines/architectures, right?<br>
<div class="im"><br>
>> b. If someone feels there is missing coverage in some area, we add increased<br>
>> tests for that area (which get run on all platforms).<br>
><br>
> If you mean adding "unknown" triple tests as much as possible, I agree.<br>
<br>
</div>I believe this statement was about the reverse: if certain<br>
target-specific coverage is required it would have to be done by<br>
writing a test that specifies /that/ target triple, not by (as is<br>
sometimes the case currently) writing a test that picks up the host<br>
triple & then running it on a machine with the desired triple to get<br>
coverage for.<br>
<div class="im"><br>
>> c. If there is some reason that running with an "unknown" host triple is<br>
>> undesirable, I propose that we set the default test triple to be<br>
>> "x86_64-pc-linux-gnu", and require deviations to be specified.<br>
><br>
> Here, I don't agree. I don't see why one platform should be the<br>
> default over another.<br>
<br>
</div>Because we would need/want a default of some kind. The argument here<br>
is: "If we can't choose some agnostic default for all tests, we should<br>
choose a non-agnostic default" - the only alternative position is that<br>
we don't choose a default but instead force every test to specify an<br>
arbitrary triple. I don't think this is substantially more valuable,<br>
though it is the current state of affairs among the tests that do have<br>
triples specified (that they are "random" in the sense that they're<br>
usually whatever architecture the developer is working on at the time<br>
- so we have lots of linux ones, lots of darwin ones, and a smattering<br>
of ARM)<br>
<div class="im"><br>
> A similar concept, but less prejudicial is: If the tests require<br>
> platform-specific features, platform-specific tests should be added.<br>
> *Only* those added will be assumed tested (for the sakes of<br>
> validation). Other architectures can add similar tests on their own<br>
> triples, if necessary / desired.<br>
<br>
</div>Yes, that's the intent. This clause (c) was only applicable to the<br>
approach overall (ie: if there are no (or no substantial) tests that<br>
can be expressed with an unknown triple then we can't really use that<br>
as a default - we'd have to pick some other default, or have no<br>
default at all & force every test to specify a triple). For specific<br>
tests that need to test platform-specific things, that is what Daniel<br>
was saying in (b) - add coverage for that area by writing a test with<br>
an explicit triple.<br>
<div class="im HOEnZb"><br>
> In a nutshell, "unknown" defaults to nothing at all, whether running<br>
> on Intel, ARM, MIPS or whatever. If you default "unknown" to the host<br>
> architecture, or to a specific architecture, the benefits of having an<br>
> "unknown" target is void, IMO.<br>
><br>
><br>
> --<br>
> cheers,<br>
> --renato<br>
><br>
> <a href="http://systemcall.org/" target="_blank">http://systemcall.org/</a><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>