From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30589 invoked by alias); 8 Jun 2011 20:39:10 -0000 Received: (qmail 30579 invoked by uid 22791); 8 Jun 2011 20:39:09 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_MF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Jun 2011 20:38:56 +0000 Received: (qmail 20379 invoked from network); 8 Jun 2011 20:38:55 -0000 Received: from unknown (HELO ?192.168.1.5?) (janisjo@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2011 20:38:55 -0000 Message-ID: <4DEFDDF1.60101@codesourcery.com> Date: Wed, 08 Jun 2011 20:51:00 -0000 From: Janis Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mike Stump CC: Richard Earnshaw , "Joseph S. Myers" , "gcc-patches@gcc.gnu.org" Subject: Re: [testsuite] skip ARM tests with conflicting options References: <4DEE8FE7.50001@codesourcery.com> <4DEEB332.2070706@codesourcery.com> <4DEEDAF0.6090100@codesourcery.com> <4DEF516C.7060703@arm.com> <4DEF953B.7050801@codesourcery.com> <8CE2E40D-64A2-4A5D-9351-BFFEC5438424@comcast.net> In-Reply-To: <8CE2E40D-64A2-4A5D-9351-BFFEC5438424@comcast.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-06/txt/msg00679.txt.bz2 On 06/08/2011 12:30 PM, Mike Stump wrote: > On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote: >> The big question is whether such a test should be run for all multilibs >> that might possibly pass the test, or only for default and for mulitlibs >> that provide the same options. > > Here, reasonable people may disagree. I suspect in the end, we'll have > both solutions, and then individual testcases will make their own decision. > A collection of testcases will tend to follow the same convention... So, for > objective-c, we face the same sort of issue, and we do what we do, and that isn't > necessarily going to match exactly what for example the gcc.arm does, nor I suspect > are we going to change just because gcc.arm changes. I think it makes sense to > cache as much as possible and skip conflicts. Taking off my testsuite maintainer > hat, I think soft conflicts with defaults should mean we run it, and punch in the > options we want. If there is something that prohibits that from working (hard > conflict), it should be skipped. Feel free to ignore this, as I don't know that > this is the best answer. I agree that the answer will be different for different tests. The problem is that in the case of a "soft conflict", the multilib options go at the end of the compile line and override the options given in the test via dg-options. That's OK if dg-options is providing defaults for when there is no similar option in the multilib options, but a problem if the test depends on the flags from dg-options being used, as when a dg-final checks for specific code generation. Then we have the choice of running the test only with the specific values specified in the test, or allowing a range of values, for mfpu or march or whatever; that gets trickier but we have the tools to do it. > I'd like to think that dg-skip-if and dg-require-effective-target and general > target selection is beefy enough to do everything we need it to, or can be made to. Right, it's easy to add new effective targets, I don't think we need new test directives. Janis