[cfe-commits] Fixing some clang tests where ARM C++ ABI differs

John McCall rjmccall at apple.com
Tue Sep 4 10:23:13 PDT 2012


On Sep 4, 2012, at 10:20 AM, David Blaikie wrote:
> On Tue, Sep 4, 2012 at 8:19 AM, David Tweed <david.tweed at arm.com> wrote:
>> There are several clang C++ tests which are failing when run on ARM purely
>> due to a combination of (1) being run without an explicit triple and (2) the
>> ARM C++ ABI specifying constructors/destructors return the "this" pointer
>> (whereas itanium based C++ ABIs return void). This patch converts these
>> tests into 3 runs: once to test elements which don't depend on constructor
>> ABI, once with an explicit x86-64 abi and once with an explicit ARM abi.
>> These tests no longer fail on ARM and have been verified to still work on
>> x86. (It looks like this constructor ABI issue also arises in a couple of
>> other tests, but these tests have additional issues on ARM and should be
>> dealt with in separate patches.)
> 
> Thanks a bunch for looking at this sort of thing, the public buildbot
> state will hopefully be the better for it (we've got several bots that
> have been red for quite a while & don't seem to get enough respect to
> be maintained green & I suspect these sort of issues might be part of
> the problem).
> 
> One question (to you & anyone else looking at this, maybe John McCall):
> 
> Do we need to test this particular ABI feature in all these test
> cases? Or could we test that we do the right thing on ARM and X86 in
> one test and then just test for one triple in the other cases (or use
> a regex to hand-wave over the return type)? That way keeping our test
> matrix down a little bit (number of separate process executions is
> pretty much the cost metric for the tests - the fewer processes, the
> faster we can all iterate).

We have explicit tests for the ARM behavior;  I don't see any reason to
duplicate them on arbitrary other tests, and it's likely that they contain
subtle target-dependencies anyway.  Explicit triples are always best.

John.



More information about the cfe-commits mailing list