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

David Tweed david.tweed at arm.com
Wed Sep 5 01:11:30 PDT 2012



-----Original Message-----
From: John McCall [mailto:rjmccall at apple.com] 
Sent: 04 September 2012 18:23
To: David Blaikie
Cc: David Tweed; cfe-commits at cs.uiuc.edu; 陳韋任
Subject: Re: [cfe-commits] Fixing some clang tests where ARM C++ ABI differs

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).

Thanks: we certainly share the view that getting the ARM buildbots having a
baseline green state would be beneficial for everyone. Could I ask, at a
convenient juncture, if you could look over the patch to give it a review
towards being committed please?

| 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.

It's an awkward question. On the one hand, clearly these tests are testing
behaviour that ought to be target independent, so we ought to be able to
have a set of tests that pick a particular ABI and just test that. On the
other hand, the reasons for these tests is to catch non-obvious breakage
early so it would be beneficial
to be testing them on various native platforms. (I'm looking at some of the
other failures and while I can't be definitive at this stage it looks like
there may be issues that show up on ARM in addition to pure ABI
differences.)

In the end it probably comes down to deciding a trade-off: does the
additional lines of checking obscure what's going on more or less than it
increases the likelihood of catching platform specific (particularly ARM)
issues? I don't have a good feel for that.

Regards
David Tweed







More information about the cfe-commits mailing list