Hi Mike,
On 01/08/14 01:00, Mike Stump wrote:
On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan <ramana....@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 <mikest...@comcast.net>
Kyrylo Tkachov <kyrylo.tkac...@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 ""
