This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Aug 11, 2014, at 2:06 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
> Not quite, read the subject line again.

Doh.  I did miss that entirely.  The solutions I gave were for other cases than the case at hand.

> I'm not sure what the correct change to the testsuite is here.

The below is close, let me refine it a little.

> Perhaps the best solution would be something like marking the test as
> "large" in some way and for "large" tests the linker would handle
> "relocation truncated to fit" errors from the linker through some target
> hook that had a better understanding of whether size related options
> were being used and could decide between error and unsupported.

How about a target tiny in supports.exp and any target that is tiny, we handle overflows in relocs as always unsupported.  Works for all tiny targets, and uniformly works for all languages and all test cases of all time.  Doesn’t depend upon guessing a size (how many bytes is tiny, is it code or data, and exactly how many bytes were generated on the target for the test case) nor guessing which test case are large.  If you test the entire test suite with the tiny flag or if that flag is the default, then supports will say that the target is tiny.  If you don’t give that flag and it isn’t the default, that same target is large.  A person that only has tiny, can just say I’m tiny, and be forever done with it.  An advanced ports with relaxation can then remove the I’m tiny, and then test relaxation.

I think that offers little code to do this (5-10 lines), handles most situations nicely, retains as much testing as possible generally speaking.

If one wants to handle mcmodel options on test cases seamlessly, one can use check-flags I think as well, see check_effective_target_arm_fp16_ok_nocache for example.

Something like:

 proc ${tool}_check_unsupported_p { output } {
    if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] {
  return "memory full”
+    if { [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $output] && [check_effective_target_tiny] } {
  return "memory full”
     }

proc check_effective_target_tiny { } {
    if { [istarget blabla-*-*]
        return 1
    }
    return 0
}

if the choice is static for the target.  Slightly more complex is check-flags is used. I’ll leave that as an exercise for the reader.  :-)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]