From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14743 invoked by alias); 7 Aug 2014 08:38:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 14732 invoked by uid 89); 7 Aug 2014 08:38:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Aug 2014 08:38:06 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Thu, 07 Aug 2014 09:38:03 +0100 Received: from [10.1.208.24] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2014 09:38:01 +0100 Message-ID: <53E33AE9.4050902@arm.com> Date: Thu, 07 Aug 2014 08:38:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mike Stump , Ramana Radhakrishnan CC: GCC Patches , Marcus Shawcroft Subject: Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny References: <53CE448E.4060109@arm.com> <558B280E-4993-4FC6-9A57-A12ECB4A9B10@comcast.net> <77E8A918-CCEF-4F2F-9E17-8866991575BE@comcast.net> In-Reply-To: X-MC-Unique: 114080709380306001 Content-Type: multipart/mixed; boundary="------------080304010907080300030207" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00772.txt.bz2 This is a multi-part message in MIME format. --------------080304010907080300030207 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-length: 3911 Hi Mike, On 01/08/14 01:00, Mike Stump wrote: > On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan 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=92t a pl= ace 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=92t. The gcc test s= uite generally speaking doesn=92t have enough of a low level system view to= manage the totality of the complexities. In reality, some folks have a me= g of ram, and 64k of code and they want to run the test suite. There are t= est cases that won=92t work, and it is rather impossible to split the hairs= and say exactly when a test case will and won=92t work. Let=92s 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 byte= s and makes it 30% faster. That goes in. We don=92t want that test case t= o fail, just because it no longer fits. Wether is fits or not, is not some= thing we get to know in the test suite; because we don=92t get to know, we = can=92t pass or fail because of it. The best we can do is know when it pas= ses and say PASS:, and notice when it doesn=92t 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, som= e already invented and some yet to be invented. Let me focus on one of the= m. It is a demand paged virtual memory system. It has 32 megs of ram on t= he machine, let say, that is the only size the machine has ever had. Do we= mark this as passing or failing? Hint I=92ve 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 m= emory system preallocated all the backing store from swap and there wasn=92= 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 enviro= nment 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 mach= ine can use swap, then you retort, but we can kill off all their processes,= then I retort, no, we can=92t, then you still wind up loosing. Now, maybe= I=92ve overlooked something trivial, maybe I don=92t understand the entire= ty of the world your envisioning=85 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=20 about relocations being truncated. I've extended your patch to catch=20 those as well. With this the tests I was seeing FAIL now are marked=20 UNSUPPORTED. How is this? Kyrill 2014-08-07 Mike Stump Kyrylo Tkachov * 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. --------------080304010907080300030207 Content-Type: text/x-patch; name=testsuite-mem-full.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="testsuite-mem-full.patch" Content-length: 2300 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 { } { # =20 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 } { } } =20 - # 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] =3D=3D "" } then { # gld so we can tell what the error text will look like. =20 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 ""= --------------080304010907080300030207--