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

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Wed, Jul 30, 2014 at 10:35 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Jul 22, 2014, at 12:14 PM, Mike Stump <mikestump@comcast.net> wrote:
>> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>>> These tests use very large arrays as part of their loop interchange testing so they don't fit into the 1MiB binary size limit imposed by -mcmodel=tiny. This causes errors at link-time.
>>
>>> Ok to commit?
>>
>> So the test suite should be used to figure this out as marking the individual test cases is a never ending and ever changing.  I can a big test case on my system, and found:
>>
>> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM'
>> ld: a.out section `.ctors' will not fit in region `SRAM'
>> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM'
>> ld: region `SRAM' overflowed by 155196160 bytes
>>
>> for large test cases.  After looking at the current gld sources, it seems that they merely changed the spelling of the error message and weâve not kept up.  Please try the patch below and tell me if it works for you.  If it doesnât, what messages do you see and what tool are they from?  Vendor, program and version would be nice to know.
>>
>> If it works, feel free to check it in.  If you want to replicate the 4 lines and add a case for the vendorâs tool, thatâd be a better way to handle it.  The below should handle a variety of GNU ld situations (but not all of them).
>
> So, were you able to test the patch I sent?



So Kyrill's away and that's probably why he hasn't tested your patch yet.

The particular errors are in the "tiny" memory model in AArch64 and
the typical messages are about relocations truncated to fit. Now, in
the tiny memory model on AArch64 it's valid to filter out the error
messages that state that "relocation was truncated to fit" which is
essentially that the program is too big.

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 testsuite ?

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


Ramana