From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91564 invoked by alias); 8 Dec 2015 10:50:15 -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 91539 invoked by uid 89); 8 Dec 2015 10:50:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Dec 2015 10:50:12 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-36-spE3o2c8QPeTLRuJ1zrSWg-1; Tue, 08 Dec 2015 10:50:03 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2015 10:50:02 +0000 Message-ID: <5666B5DA.90104@arm.com> Date: Tue, 08 Dec 2015 10:50:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christophe Lyon , "gcc-patches@gcc.gnu.org" Subject: Re: [testsuite][ARM target attributes] Fix effective_target tests References: In-Reply-To: X-MC-Unique: spE3o2c8QPeTLRuJ1zrSWg-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00839.txt.bz2 Hi Christophe, On 27/11/15 13:00, Christophe Lyon wrote: > Hi, > > After the recent commits from Christian adding target attributes > support for ARM FPU settings, I've noticed that some of the tests > were failing because of incorrect assumptions wrt to the default > cpu/fpu/float-abi of the compiler. > > This patch fixes the problems I've noticed in the following way: > - do not force -mfloat-abi=3Dsoftfp in dg-options, to avoid conflicts > when gcc is configured --with-float=3Dhard > > - change arm_vfp_ok such that it tries several -mfpu/-mfloat-abi > flags, checks that __ARM_FP is defined and __ARM_NEON_FP is not > defined > > - introduce arm_fp_ok, which is similar but does not enforce fpu setting > > - add a new effective_target: arm_crypto_pragma_ok to check that > setting this fpu via a pragma is actually supported by the current > "multilib". This is different from checking the command-line option > because the pragma might conflict with the command-line options in > use. > > The updates in the testcases are as follows: > - attr-crypto.c, we have to make sure that the defaut fpu does not > conflict with the one forced by pragma. That's why I use the arm_vfp > options/effective_target. This is needed if gcc has been configured > --with-fpu=3Dneon-fp16, as the pragma fpu=3Dcrypto-neon-fp-armv8 would > conflict. > > - attr-neon-builtin-fail.c: use arm_fp to force the appropriate > float-abi setting. Enforcing fpu is not needed here. > > - attr-neon-fp16.c: similar, I also removed arm_neon_ok since it was > not necessary to make the test pass in my testing. On second thought, > I'm wondering whether I should leave it and make the test unsupported > in more cases (such as when forcing -march=3Darmv5t, although it does > pass with this patch) > > - attr-neon2.c: use arm_vfp to force the appropriate float-abi > setting. Enforcing mfpu=3Dvfp is needed to avoid conflict with the > pragma target fpu=3Dneon (for instance if the toolchain default is > neon-fp16) > > - attr-neon3.c: similar > > Tested on a variety of configurations, see: > http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patch= es/230929-target-attr/report-build-info.html > > Note that the regressions reported fall into 3 categories: > - when forcing march=3Darmv5t: tests are now unsupported because I > modified arm_crypto_ok to require arm_v8_neon_ok instead of arm32. > > - the warning reported by attr-neon-builtin-fail.c moved from line 12 > to 14 and is thus seen as a regression + one improvement > > - finally, attr-neon-fp16.c causes an ICE on armeb compilers, for > which I need to post a bugzilla. > > > TBH, I'm a bit concerned by the complexity of all these multilib-like > conditions. I'm confident that I'm still missing some combinations :-) > > And with new target attributes coming, new architectures etc... all > this logic is likely to become even more complex. > > That being said, OK for trunk? I'd like us to clean up and reorganise the gcc.target/arm testsuite at some point to make it more robust with respect to the tons of multilib options and configurations we can have for arm. It's becoming very frustrat= ing to test feature-specific stuff :( This is ok in the meantime. Sorry for the delay. Thanks for handling this! Kyrill > Christophe > > > 2015-11-27 Christophe Lyon > > * lib/target-supports.exp > (check_effective_target_arm_vfp_ok_nocache): New. > (check_effective_target_arm_vfp_ok): Call the new > check_effective_target_arm_vfp_ok_nocache function. > (check_effective_target_arm_fp_ok_nocache): New. > (check_effective_target_arm_fp_ok): New. > (add_options_for_arm_fp): New. > (check_effective_target_arm_crypto_ok_nocache): Require > target_arm_v8_neon_ok instead of arm32. > (check_effective_target_arm_crypto_pragma_ok_nocache): New. > (check_effective_target_arm_crypto_pragma_ok): New. > (add_options_for_arm_vfp): New. > * gcc.target/arm/attr-crypto.c: Use arm_crypto_pragma_ok effective > target. Do not force -mfloat-abi=3Dsoftfp, use arm_vfp effective > target instead. > * gcc.target/arm/attr-neon-builtin-fail.c: Do not force > -mfloat-abi=3Dsoftfp, use arm_fp effective target instead. > * gcc.target/arm/attr-neon-fp16.c: Likewise. Remove arm_neon_ok > dependency. > * gcc.target/arm/attr-neon2.c: Do not force -mfloat-abi=3Dsoftfp, > use arm_vfp effective target instead. > * gcc.target/arm/attr-neon3.c: Likewise.