From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 584 invoked by alias); 1 Aug 2014 00:00:34 -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 560 invoked by uid 89); 1 Aug 2014 00:00:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: qmta09.emeryville.ca.mail.comcast.net Received: from qmta09.emeryville.ca.mail.comcast.net (HELO qmta09.emeryville.ca.mail.comcast.net) (76.96.30.96) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Aug 2014 00:00:32 +0000 Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta09.emeryville.ca.mail.comcast.net with comcast id ZBzw1o0010cQ2SLA9C0WFU; Fri, 01 Aug 2014 00:00:30 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by omta10.emeryville.ca.mail.comcast.net with comcast id ZC0V1o00S2ztT3H8WC0VKi; Fri, 01 Aug 2014 00:00:30 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny From: Mike Stump In-Reply-To: Date: Fri, 01 Aug 2014 00:00:00 -0000 Cc: Kyrill Tkachov , GCC Patches , Marcus Shawcroft Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CE448E.4060109@arm.com> <558B280E-4993-4FC6-9A57-A12ECB4A9B10@comcast.net> <77E8A918-CCEF-4F2F-9E17-8866991575BE@comcast.net> To: ramrad01@arm.com X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00000.txt.bz2 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 li= nker is a fine place for such a tescase. The gcc test suite isn=92t a plac= e for such a test case if you want to test other than it works ok when it f= its and to have it marked as unsupported if it doesn=92t. The gcc test sui= te generally speaking doesn=92t have enough of a low level system view to m= anage 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 tes= t cases that won=92t work, and it is rather impossible to split the hairs a= nd 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 th= e compiler by adding an optimization that expands the code size by 4 bytes = and makes it 30% faster. That goes in. We don=92t want that test case to = fail, just because it no longer fits. Wether is fits or not, is not someth= ing we get to know in the test suite; because we don=92t get to know, we ca= n=92t pass or fail because of it. The best we can do is know when it passe= s 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, 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 m= ark this as passing or failing? Hint I=92ve engineered this so that you ca= nnot win. The problem is, if you say fail, I say it is demand paged, and i= t works. If you say it works, I say it fails, because the demand paged mem= ory system preallocated all the backing store from swap and there wasn=92t = enough swap space to support it. You can attempt to say, ah, but the test s= uite is turning complete and we can write some tcl code to check out much s= wap space there is and set it up correctly, then I retort that the environm= ent impinges the data space on this machine, then you retort, but we can th= en check the environment, and then I retort, but another user on the machin= e can use swap, then you retort, but we can kill off all their processes, t= hen 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 entirety= 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.