Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny

[Mike Stump <mikestump at comcast dot net>]

On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan <ramana.gcc@googlemail.com> wrote:
> However if we have a situation where a port tries to ameliorate some
> of these errors with linker veneering and the compiler testsuite peels
> off such error messages and just marks them as UNSUPPORTED instead of
> getting a failure, is that the right behaviour in the test suite ?

A link editor test suite to ensure you implemented complex things in the linker is a fine place for such a tescase.  The gcc test suite isn’t a place for such a test case if you want to test other than it works ok when it fits and to have it marked as unsupported if it doesn’t.  The gcc test suite generally speaking doesn’t have enough of a low level system view to manage the totality of the complexities.  In reality, some folks have a meg of ram, and 64k of code and they want to run the test suite.  There are test cases that won’t work, and it is rather impossible to split the hairs and say exactly when a test case will and won’t work.  Let’s say your 1 byte inside the limits on ram for a test case T.  Then, someone improved the compiler by adding an optimization that expands the code size by 4 bytes and makes it 30% faster.  That goes in.  We don’t want that test case to fail, just because it no longer fits.  Wether is fits or not, is not something we get to know in the test suite; because we don’t get to know, we can’t pass or fail because of it.  The best we can do is know when it passes and say PASS:, and notice when it doesn’t fit and say UNSUPPORTED:.

> I may be missing something here but it does sound like we may want 2
> slightly different behaviours possible here.

Nope.  Consider:

#define N 100*1024*1024

char a[N];

main() {
}

and 100 different systems that this test case will run this test one, some already invented and some yet to be invented.  Let me focus on one of them.  It is a demand paged virtual memory system.  It has 32 megs of ram on the machine, let say, that is the only size the machine has ever had.  Do we mark this as passing or failing?  Hint I’ve engineered this so that you cannot win.  The problem is, if you say fail, I say it is demand paged, and it works.  If you say it works, I say it fails, because the demand paged memory system preallocated all the backing store from swap and there wasn’t enough swap space to support it. You can attempt to say, ah, but the test suite is turning complete and we can write some tcl code to check out much swap space there is and set it up correctly, then I retort that the environment impinges the data space on this machine, then you retort, but we can then check the environment, and then I retort, but another user on the machine can use swap, then you retort, but we can kill off all their processes, then I retort, no, we can’t, then you still wind up loosing.  Now, maybe I’ve overlooked something trivial, maybe I don’t understand the entirety of the world your envisioning…  If you want to describe it, feel free.

In short, the gcc test suite is not the proper place to test veneers for ld.  We can test some of that support, just there are limits to it.