From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4082 invoked by alias); 29 Jun 2011 16:08:04 -0000 Received: (qmail 4074 invoked by uid 22791); 29 Jun 2011 16:08:03 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f49.google.com (HELO mail-fx0-f49.google.com) (209.85.161.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jun 2011 16:07:49 +0000 Received: by fxd20 with SMTP id 20so1195144fxd.22 for ; Wed, 29 Jun 2011 09:07:48 -0700 (PDT) Received: by 10.223.9.217 with SMTP id m25mr1406399fam.122.1309363668166; Wed, 29 Jun 2011 09:07:48 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice3n2.emea.ibm.com [195.212.29.84]) by mx.google.com with ESMTPS id k26sm947400fak.0.2011.06.29.09.07.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 09:07:47 -0700 (PDT) From: Richard Sandiford To: Janis Johnson Mail-Followup-To: Janis Johnson ,Richard Earnshaw , Ramana Radhakrishnan , "gcc-patches\@gcc.gnu.org" , richard.sandiford@linaro.org Cc: Richard Earnshaw , Ramana Radhakrishnan , "gcc-patches\@gcc.gnu.org" Subject: Re: [testsuite] skip ARM tests if no thumb2 support References: <4DF7C61F.4030303@codesourcery.com> <4DF8DFF8.4080307@codesourcery.com> <4E0B2EC8.3010901@arm.com> <4E0B40B7.2060008@codesourcery.com> Date: Wed, 29 Jun 2011 16:23:00 -0000 In-Reply-To: <4E0B40B7.2060008@codesourcery.com> (Janis Johnson's message of "Wed, 29 Jun 2011 08:11:51 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg02254.txt.bz2 Janis Johnson writes: > On 06/29/2011 06:55 AM, Richard Earnshaw wrote: >> I'd posit a third option: >> >> 3. Add a new dg directive (perhaps dg-ignore-multilib) that instructs >> the framework to ignore the multilib options entirely (only supported >> for compile/assembly tests). >> >> There are a lot of target-specific tests that are not really testing >> execution, just that the compiler generates the right instruction under >> specific compilation options. It seems silly to force all this into the >> multi-lib framework. >> >> R. > > The MIPS tests have support for something like that that, but it seems > to me that if tests are being run for lots of multilibs then it's > better to test things like code generation for a variety of relevant > options instead of using the same options every time. I might be misunderstanding what you mean, but the MIPS version tries to keep as many of the original options as possible, only overriding those that are known to be incompatible with the test. So e.g. a test for a MIPS IV feature will run normally on a MIPS IV-compatible target, but will override the architecture on other targets. That said, I wouldn't recommend the mips.exp approach to anyone. It's been useful, and it seems to do what it's meant to, but it's a very... heavy-weight approach. Richard