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


Hi Mike,

On 01/08/14 01:00, Mike Stump wrote:
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.

Thanks for the detailed explanation, the linker errors I was seeing were about relocations being truncated. I've extended your patch to catch those as well. With this the tests I was seeing FAIL now are marked UNSUPPORTED.

How is this?

Kyrill

2014-08-07  Mike Stump  <mikestump@comcast.net>
                    Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

    * lib/gcc-defs.exp (${tool}_check_unsupported_p):
    Add check for oveflow and relocation truncation linker errors.
    * lib/gcc-dg.exp (gcc-dg-prune): Likewise.
    * lib/objc.exp (${tool}_check_unsupported_p): Likewise.
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index 69a5971..8ea1f55 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -154,7 +154,8 @@ proc ${tool}_exit { } {
 #
 
 proc ${tool}_check_unsupported_p { output } {
-    if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] {
+    if { [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $output] \
+         || [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $output] } {
 	return "memory full"
     }
     if { [istarget spu-*-*] && \
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 3390caa..d8f921a 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -225,10 +225,13 @@ proc gcc-dg-prune { system text } {
 	}
     }
 
-    # If we see "region xxx is full" then the testcase is too big for ram.
-    # This is tricky to deal with in a large testsuite like c-torture so
-    # deal with it here.  Just mark the testcase as unsupported.
-    if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $text] {
+    # If we see "region xxx is full" or "region xxx overflowed by "
+    # or "relocation truncated to fit"
+    # then the testcase is too big for ram.  This is tricky to deal
+    # with in a large testsuite like c-torture so deal with it here.
+    # Just mark the testcase as unsupported.
+    if { [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $text] \
+         || [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $text] } {
 	# The format here is important.  See dg.exp.
 	return "::unsupported::memory full"
     }
diff --git a/gcc/testsuite/lib/objc.exp b/gcc/testsuite/lib/objc.exp
index 5ecefa9..45d9de1 100644
--- a/gcc/testsuite/lib/objc.exp
+++ b/gcc/testsuite/lib/objc.exp
@@ -354,7 +354,8 @@ if { [info procs prune_warnings] == "" } then {
 # gld so we can tell what the error text will look like.
 
 proc ${tool}_check_unsupported_p { output } {
-    if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] {
+    if { [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $output] \
+         || [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $output] } {
 	return "memory full"
     }
     return ""

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