The example I was giving was a "thinly generalized" version of the devirtualisation issue: what was happening was that a destructor, which on ARM ABI is returns "this", was being devirtualised and a function with the return type of the base class prototype was being added whereas it ought to have been the return type of the actual function being inlined. (Devirt can't do general covariant returns, but I gather that no-one actually uses destructor return types anyway.) On x86_64 the return type of a destructor is always void, so getting the type from the base class prototype gives the same result. I know it's a matter of semantics: was that code actually "a latent bug" on x86_64 when it would always be guaranteed to produce the right code (on that platform)?<br>
<br>I know this is a ridiculously specific example, and I don't know if similar effects can happen elsewhere, I just have this feeling that picking the simplest platform it's more likely for stuff to pass even if there's a minor latent issue. But I can't back that up with any facts.<br>
<br>As for proposed solutions, I can't say I really have anything that counts as a solution. I think I need to see what "unknown" actually implies in terms of behaviour/code-paths, it's just that if it's equivalent to "the simplest, most vanilla target" it may be less effective in finding issues. But again, that's just a feeling.<br>
<br>Regards,<br>Dave<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 6:59 PM, 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 9:21 AM, David Tweed <<a href="mailto:david.tweed@arm.com">david.tweed@arm.com</a>> wrote:<br>

> -----Original Message-----<br>
> From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a>] On<br>
> Behalf Of David Blaikie<br>
> Sent: 03 December 2012 16:41<br>
> To: Renato Golin<br>
> Cc: LLVM Developers Mailing List; cfe-dev<br>
> Subject: Re: [cfe-dev] [LLVMdev] RFC: Change tests to run with fixed<br>
> (not-host dependent) triple<br>
><br>
</div><div class="im">>>> 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>
> | 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>
><br>
</div><div class="im">> Just a point here: the reason I'd mildly prefer not to have a default that<br>
> avoids as much target dependent stuff as possible is that it's generally<br>
> going to have a higher probability of passing even if something is "wrong"<br>
> in the sense that, eg, if the return type of some thing is ABI mandated to<br>
> be void, then you could be getting the type from the wrong place and still<br>
> pass since all places give the same result;<br>
<br>
</div>Sorry, I think I lost track of this example around here. What do you<br>
mean by "getting the type from the wrong place"?<br>
What sort of solution are you proposing?<br>
<br>
What I think we're discussing here is:<br>
All tests without a triple be written in such a way as to pass for any<br>
triple (& there would be test infrastructure to help ensure this) &<br>
that the default would be a fixed "unknown" triple, or an arbitrary<br>
(but constant/singular) concrete triple.<br>
<br>
What is it you have in mind?<br>
<div class="im"><br>
>  if you happen to be doing this<br>
> on an ABI where the where the value differs depending where it is obtained<br>
> from then you'll probably catch errors that are "latent errors" for the<br>
> simpler ABI. (Yes, this is a thinly disguised version of the<br>
> devirtualisation issue, but I do think this phenomenon may apply elsewhere:<br>
> the less complicated an ABI the more chance that something "slightly wrong"<br>
> will actually pass.) Those are my thoughts anyway.<br>
><br>
</div>> Regards,<br>
> Dave<br>
<div class="HOEnZb"><div class="h5">><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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>cheers, dave tweed__________________________</div><div>high-performance computing and machine vision expert: <a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a></div>
<div>"while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot</div><div> </div><br>
</div>