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

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

[Kyrill Tkachov]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Hi all,

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.

Skip them when that is the case.

Ok to commit?

Thanks,
Kyrill

2014-07-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * gcc.dg/graphite/interchange-0.c: Skip on aarch64 tiny memory model.
     * gcc.dg/graphite/interchange-1.c: Likewise.
     * gcc.dg/graphite/interchange-2.c: Likewise.
     * gcc.dg/graphite/interchange-3.c: Likewise.
     * gcc.dg/graphite/interchange-4.c: Likewise.
     * gcc.dg/graphite/interchange-10.c: Likewise.
     * gcc.dg/graphite/interchange-11.c: Likewise.
     * gcc.dg/graphite/interchange-15.c: Likewise.
     * gcc.dg/graphite/interchange-mvt.c: Likewise.
     * gcc.dg/graphite/pr46185.c: Likewise.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: aarch64-graphite-tiny.patch --]
[-- Type: text/x-patch; name=aarch64-graphite-tiny.patch, Size: 4896 bytes --]

commit 1c4e93c3cd0904fc2860fc7c4f9f1e0bffc72d2c
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date:   Wed Jul 16 16:29:58 2014 +0100

    [AArch64] Skip some graphite tests for -mcmodel=tiny

diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-0.c b/gcc/testsuite/gcc.dg/graphite/interchange-0.c
index 8bc6e13..58e24b6 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-0.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-0.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 #define DEBUG 0
 
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-1.c b/gcc/testsuite/gcc.dg/graphite/interchange-1.c
index b4559d1..bf725d7 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-1.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-1.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 /* Formerly known as ltrans-1.c */
 
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-10.c b/gcc/testsuite/gcc.dg/graphite/interchange-10.c
index 51a46d6..4a38d2c 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-10.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-10.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 #define DEBUG 0
 #if DEBUG
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-11.c b/gcc/testsuite/gcc.dg/graphite/interchange-11.c
index 491fda1..214e8f1 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-11.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-11.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 #define DEBUG 0
 #if DEBUG
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-15.c b/gcc/testsuite/gcc.dg/graphite/interchange-15.c
index d154b74..e5d52aa 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-15.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-15.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 #define DEBUG 0
 #if DEBUG
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-2.c b/gcc/testsuite/gcc.dg/graphite/interchange-2.c
index 2609a10..a199be5 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-2.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-2.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 /* Formerly known as ltrans-2.c */
 
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-3.c b/gcc/testsuite/gcc.dg/graphite/interchange-3.c
index 1419749..7d4d1e2 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-3.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-3.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 /* Formerly known as ltrans-3.c */
 
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-4.c b/gcc/testsuite/gcc.dg/graphite/interchange-4.c
index f86391c..806a57f 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-4.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-4.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 /* Formerly known as ltrans-4.c */
 
diff --git a/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c b/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c
index f446dbe..f10efa5 100644
--- a/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c
+++ b/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target size32plus } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 
 #define DEBUG 0
 #if DEBUG
diff --git a/gcc/testsuite/gcc.dg/graphite/pr46185.c b/gcc/testsuite/gcc.dg/graphite/pr46185.c
index 36d46a4..646a733 100644
--- a/gcc/testsuite/gcc.dg/graphite/pr46185.c
+++ b/gcc/testsuite/gcc.dg/graphite/pr46185.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-skip-if "AArch64 tiny code model does not support programs larger than 1MiB" {aarch64_tiny} {"*"} {""} } */
 /* { dg-options "-O2 -floop-interchange -ffast-math -fno-ipa-cp" } */
 
 #define DEBUG 0

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

[Sebastian Pop]

On Tue, Jul 22, 2014 at 6:01 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> Hi all,
>
> 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.
>
> Skip them when that is the case.
>
> Ok to commit?

Looks good to me.
Please wait for the review of a maintainer of the testsuite before committing.

Thanks,
Sebastian

>
> Thanks,
> Kyrill
>
> 2014-07-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>
>     * gcc.dg/graphite/interchange-0.c: Skip on aarch64 tiny memory model.
>     * gcc.dg/graphite/interchange-1.c: Likewise.
>     * gcc.dg/graphite/interchange-2.c: Likewise.
>     * gcc.dg/graphite/interchange-3.c: Likewise.
>     * gcc.dg/graphite/interchange-4.c: Likewise.
>     * gcc.dg/graphite/interchange-10.c: Likewise.
>     * gcc.dg/graphite/interchange-11.c: Likewise.
>     * gcc.dg/graphite/interchange-15.c: Likewise.
>     * gcc.dg/graphite/interchange-mvt.c: Likewise.
>     * gcc.dg/graphite/pr46185.c: Likewise.

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

[Kyrill Tkachov]

On 22/07/14 16:01, Sebastian Pop wrote:
> On Tue, Jul 22, 2014 at 6:01 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>> Hi all,
>>
>> 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.
>>
>> Skip them when that is the case.
>>
>> Ok to commit?
> Looks good to me.
> Please wait for the review of a maintainer of the testsuite before committing.

Thanks for having a look.
CC'ing Mike as testsuite maintainer then...

Kyrill

> Thanks,
> Sebastian
>
>> Thanks,
>> Kyrill
>>
>> 2014-07-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>>
>>      * gcc.dg/graphite/interchange-0.c: Skip on aarch64 tiny memory model.
>>      * gcc.dg/graphite/interchange-1.c: Likewise.
>>      * gcc.dg/graphite/interchange-2.c: Likewise.
>>      * gcc.dg/graphite/interchange-3.c: Likewise.
>>      * gcc.dg/graphite/interchange-4.c: Likewise.
>>      * gcc.dg/graphite/interchange-10.c: Likewise.
>>      * gcc.dg/graphite/interchange-11.c: Likewise.
>>      * gcc.dg/graphite/interchange-15.c: Likewise.
>>      * gcc.dg/graphite/interchange-mvt.c: Likewise.
>>      * gcc.dg/graphite/pr46185.c: Likewise.

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

[Mike Stump]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

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



[-- Attachment #2: full.diffs.txt --]
[-- Type: text/plain, Size: 2039 bytes --]

diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index 69a5971..58c6a9f 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -154,7 +154,7 @@ 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] {
 	return "memory full"
     }
     if { [istarget spu-*-*] && \
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index a758d47..bc6ba97 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -225,10 +225,11 @@ 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 "
+    # 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] {
 	# 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..6a1c2e7 100644
--- a/gcc/testsuite/lib/objc.exp
+++ b/gcc/testsuite/lib/objc.exp
@@ -354,7 +354,7 @@ 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] {
 	return "memory full"
     }
     return ""

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

[Mike Stump]

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?

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

[Mike Stump]

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.

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

[Kyrill Tkachov]

[-- Attachment #1: Type: text/plain, Size: 3848 bytes --]

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.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: testsuite-mem-full.patch --]
[-- Type: text/x-patch; name=testsuite-mem-full.patch, Size: 2325 bytes --]

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

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

[Mike Stump]

On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> 
> Thanks for the detailed explanation, the linker errors I was seeing were about relocations being truncated.

Ah, those are bugs in your port!  You should be able to generate large code and then relax it into short small code.  Large code, by definition, will never run into relocs 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?

No.  :-(

Those are traditionally bugs in gcc that users want gcc to fix.  Paper overing those bugs is the wrong path forward.

So, a couple of ideas come to mind.  The best, add relation and generate large by default.  Next solution, is to have a linker script that limits memory to the size that the large reloc supports.  If it is 18 bits, then limit memory to 18 bits.  Doesn’t impact normal users as they only have 18 bits or less on their system.  Next up, add a -mcmodel=large and make it the default and have people that want small code use -mcmodel=small.  Another solution is to add a non-default -mc-model=large, and generate large code with that option, and then fix the specific test cases in the gcc test suite that fail to use that option on your target.  This is a small maintenance nightmare, but…

So, which one do you like?

The model option (I just got done doing one for mine).  I was building gcc for my target, which only the simulator can run due to memory sizes and hit the relocs don’t fit.  I fixed it by 2 lines of work, one in branch and one in call, that removed the displacement forms under large model.  Generates gross code, but I only need it for testing.  For production, we default to and use small.  The reality is that while the other instruction might theoretically hit the reloc limits, in practice they don’t.

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

[Richard Earnshaw]

On 08/08/14 18:53, Mike Stump wrote:
> On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>>
>> Thanks for the detailed explanation, the linker errors I was seeing were about relocations being truncated.
> 
> Ah, those are bugs in your port!  You should be able to generate large code and then relax it into short small code.  Large code, by definition, will never run into relocs 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?
> 
> No.  :-(
> 
> Those are traditionally bugs in gcc that users want gcc to fix.  Paper overing those bugs is the wrong path forward.
> 

Not quite, read the subject line again.

This particular case the user (test) has asserted that the image will
fit in a certain amount of memory; but in fact that turns out to be
false.  This can only be detected at link time when the relocations
overflow - it's by definition impossible to detect during the
compilation phase.

I'm not sure what the correct change to the testsuite is here.  Any test
failures like this are likely to be somewhat target specific.  In the
worst case the optimization level may affect what can be made to fit.
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.

R.

> So, a couple of ideas come to mind.  The best, add relation and generate large by default.  Next solution, is to have a linker script that limits memory to the size that the large reloc supports.  If it is 18 bits, then limit memory to 18 bits.  Doesn’t impact normal users as they only have 18 bits or less on their system.  Next up, add a -mcmodel=large and make it the default and have people that want small code use -mcmodel=small.  Another solution is to add a non-default -mc-model=large, and generate large code with that option, and then fix the specific test cases in the gcc test suite that fail to use that option on your target.  This is a small maintenance nightmare, but…
> 
> So, which one do you like?
> 
> The model option (I just got done doing one for mine).  I was building gcc for my target, which only the simulator can run due to memory sizes and hit the relocs don’t fit.  I fixed it by 2 lines of work, one in branch and one in call, that removed the displacement forms under large model.  Generates gross code, but I only need it for testing.  For production, we default to and use small.  The reality is that while the other instruction might theoretically hit the reloc limits, in practice they don’t.
> 

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

[Mike Stump]

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

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

[Kyrill Tkachov]

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]


On 11/08/14 18:34, Mike Stump wrote:
> 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.  :-)
>

So how about this?

We add a check_effective_target_tiny (and define it for aarch64) and 
when find a "relocation truncated" message we say it's unsupported only 
when check_effective_target_tiny holds.

Kyrill


2014-08-19  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * lib/gcc-defs.exp (${tool}_check_unsupported_p):
     Return memory full when we have a tiny target and relocation
     truncation occurs.
     * lib/gcc-dg.exp (gcc-dg-prune): Likewise.
     * lib/objc.exp (${tool}_check_unsupported_p): Likewise.
     * lib/target-supports.exp (check_effective_target_tiny): New function.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: testsuite-mem-full.patch --]
[-- Type: text/x-patch; name=testsuite-mem-full.patch, Size: 2414 bytes --]

diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index 69a5971..1ea7028 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -157,6 +157,11 @@ 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"
+     }
+
     if { [istarget spu-*-*] && \
 	     [string match "*exceeds local store*" $output] } {
 	return "memory full"
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 3390caa..dfdb257 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -233,6 +233,11 @@ proc gcc-dg-prune { system text } {
 	return "::unsupported::memory full"
     }
 
+    if { [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $text]
+          && [check_effective_target_tiny] } {
+        return "::unsupported::memory full"
+    }
+
     # Likewise, if we see ".text exceeds local store range" or
     # similar.
     if {[string match "spu-*" $system] && \
diff --git a/gcc/testsuite/lib/objc.exp b/gcc/testsuite/lib/objc.exp
index 5ecefa9..e19b264 100644
--- a/gcc/testsuite/lib/objc.exp
+++ b/gcc/testsuite/lib/objc.exp
@@ -357,6 +357,10 @@ 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"
+    }
     return ""
 }
 
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index c03370d..9eed181 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5950,6 +5950,14 @@ proc check_effective_target_fenv_exceptions {} {
     } [add_options_for_ieee "-std=gnu99"]]
 }
 
+proc check_effective_target_tiny {} {
+    if { [istarget aarch64*-*-*]
+         && [check_effective_target_aarch64_tiny] } {
+        return 1
+    }
+    return 0
+}
+
 # Return 1 if LOGICAL_OP_NON_SHORT_CIRCUIT is set to 0 for the current target.
 
 proc check_effective_target_logical_op_short_circuit {} {

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

[Mike Stump]

On Aug 19, 2014, at 6:12 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> So how about this?

Ok.  Thanks.

[PATCH][dejagnu] gcc-dg-prune glitch when filtering "relocation truncation" error

[Jiong Wang]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]


On 19/08/14 17:30, Mike Stump wrote:
> On Aug 19, 2014, at 6:12 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>> So how about this?
> Ok.  Thanks.

looks like this patch only fixed one invoke path.

currently, "gcc-dg-prune" may be invoked directly *or* via ${tool}_check_compile:

and "gcc-dg-prune" is implemented to return "::unsupported::memory full" if the input
message contains the "relocation truncated" error pattern.

this return message it OK if it's invoked directly, while it will be wrong if it's invoked
via ${tool}_check_compile. because the ${tool}_check_compile has a duplicated check of unsupported
testcase later via "${tool}_check_unsupported_p" which only works with original output message by
matching the "relocation truncation" keyword. So, our early hijack of the error in gcc-dg-prune
will replace those keywords to "::unsupported::memory" which confuse the later check.

this patch doing the following cleanup:

* modify the expected output in ${tool}_check_compile.
   if "gcc-dg-prune" invoked, then we expect "::unsupported::" keyword for unsupported testcase.

* remove the duplicated "unresolve" report in compat.exp.
   for all ${tool}_check_compile return 0, the issue is handled already. No need to report a redundant status.

ok for trunk?

gcc/testsuite/
   * lib/compat.exp (compat-run): Remove "unresolved".
   * lib/gcc-defs.exp (${tools}_check_compile): Update code logic for unsupported testcase.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fix-deja-v2.patch --]
[-- Type: text/x-patch; name=fix-deja-v2.patch, Size: 1510 bytes --]

diff --git a/gcc/testsuite/lib/compat.exp b/gcc/testsuite/lib/compat.exp
index 7ab85aa..45cf0e0 100644
--- a/gcc/testsuite/lib/compat.exp
+++ b/gcc/testsuite/lib/compat.exp
@@ -134,7 +134,6 @@ proc compat-run { testname objlist dest optall optfile optstr } {
 		     "$options"]
     if ![${tool}_check_compile "$testcase $testname link" "" \
 	 $dest $comp_output] then {
-	unresolved "$testcase $testname execute $optstr"
 	return
     }
 
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index cb93238..d479667 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -54,12 +54,17 @@ proc ${tool}_check_compile {testcase option objname gcc_output} {
     if { [info proc ${tool}-dg-prune] != "" } {
 	global target_triplet
 	set gcc_output [${tool}-dg-prune $target_triplet $gcc_output]
-    }
-
-    set unsupported_message [${tool}_check_unsupported_p $gcc_output]
-    if { $unsupported_message != "" } {
-	unsupported "$testcase: $unsupported_message"
-	return 0
+	if [string match "*::unsupported::*" $gcc_output] then {
+	    regsub -- "::unsupported::" $gcc_output "" gcc_output
+	    unsupported "$testcase: $gcc_output"
+	    return 0
+	}
+    } else {
+	set unsupported_message [${tool}_check_unsupported_p $gcc_output]
+	if { $unsupported_message != "" } {
+	    unsupported "$testcase: $unsupported_message"
+	    return 0
+	}
     }

     # remove any leftover LF/CR to make sure any output is legit

Re: [PATCH][dejagnu] gcc-dg-prune glitch when filtering "relocation truncation" error

[Jeff Law]

On 10/21/14 14:07, Jiong Wang wrote:
>
> On 19/08/14 17:30, Mike Stump wrote:
>> On Aug 19, 2014, at 6:12 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com>
>> wrote:
>>> So how about this?
>> Ok.  Thanks.
>
> looks like this patch only fixed one invoke path.
>
> currently, "gcc-dg-prune" may be invoked directly *or* via
> ${tool}_check_compile:
>
> and "gcc-dg-prune" is implemented to return "::unsupported::memory full"
> if the input
> message contains the "relocation truncated" error pattern.
>
> this return message it OK if it's invoked directly, while it will be
> wrong if it's invoked
> via ${tool}_check_compile. because the ${tool}_check_compile has a
> duplicated check of unsupported
> testcase later via "${tool}_check_unsupported_p" which only works with
> original output message by
> matching the "relocation truncation" keyword. So, our early hijack of
> the error in gcc-dg-prune
> will replace those keywords to "::unsupported::memory" which confuse the
> later check.
>
> this patch doing the following cleanup:
>
> * modify the expected output in ${tool}_check_compile.
>    if "gcc-dg-prune" invoked, then we expect "::unsupported::" keyword
> for unsupported testcase.
>
> * remove the duplicated "unresolve" report in compat.exp.
>    for all ${tool}_check_compile return 0, the issue is handled already.
> No need to report a redundant status.
>
> ok for trunk?
>
> gcc/testsuite/
>    * lib/compat.exp (compat-run): Remove "unresolved".
>    * lib/gcc-defs.exp (${tools}_check_compile): Update code logic for
> unsupported testcase.
OK.

jeff