From patchwork Wed Aug 18 10:45:08 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jie Zhang X-Patchwork-Id: 62028 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 79520B70D3 for ; Wed, 18 Aug 2010 20:45:21 +1000 (EST) Received: (qmail 11824 invoked by alias); 18 Aug 2010 10:45:19 -0000 Received: (qmail 11798 invoked by uid 22791); 18 Aug 2010 10:45:17 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, 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, 18 Aug 2010 10:45:12 +0000 Received: (qmail 11717 invoked from network); 18 Aug 2010 10:45:10 -0000 Received: from unknown (HELO ?192.168.1.100?) (jie@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Aug 2010 10:45:10 -0000 Message-ID: <4C6BB9B4.3040302@codesourcery.com> Date: Wed, 18 Aug 2010 18:45:08 +0800 From: Jie Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Chung-Lin Tang CC: Mark Mitchell , GCC Patches Subject: Re: [testsuite, ARM] Fix gcc.dg/builtin-apply2.c for ARM EABI References: <4C61573F.1070400@codesourcery.com> <4C6AB907.8030005@codesourcery.com> <4C6AE91D.3050308@codesourcery.com> In-Reply-To: <4C6AE91D.3050308@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 08/18/2010 03:55 AM, Chung-Lin Tang wrote: > Mark Mitchell wrote: >> Jie Zhang wrote: >>> When testing GCC on a Cortex-M4 board, gcc.dg/builtin-apply2.c will hang >>> the testing. That is because we should not use 64 as the size of the >>> stack argument. For ARM EABI, NAME is passed in r0. D is passed in r2 >>> and r3. E, F and G are passed on stack. >> >> Is this true in all variants of the ABI? Or do we need to worry about >> hard-float vs. soft-float ABIs? > This test is skipped for hard-float, due to the case of passing > arguments to a variadic function; it simply won't pass under > -mfloat-abi=hard. > Yes. It will be skipped when -mfloat-abi=hard. > Jie, while you're at it, why not use the new __ARM_PCS symbol instead of > __ARM_EABI__? > It more accurately marks the softfp conventions you're trying to assume > here. > Yes, it's a little better to use __ARM_PCS here. The patch is updated. Thanks. OK now? * gcc.dg/builtin-apply2.c (STACK_ARGUMENTS_SIZE): Define to 20 if __ARM_PCS is defined otherwise 64. (bar): Use STACK_ARGUMENTS_SIZE for the third argument instead of hard coded 64. Index: gcc.dg/builtin-apply2.c =================================================================== --- gcc.dg/builtin-apply2.c (revision 163327) +++ gcc.dg/builtin-apply2.c (working copy) @@ -8,10 +8,19 @@ /* Verify that __builtin_apply behaves correctly on targets with pre-pushed arguments (e.g. SPARC). */ - + #define INTEGER_ARG 5 +#ifdef __ARM_PCS +/* For Base AAPCS, NAME is passed in r0. D is passed in r2 and r3. + E, F and G are passed on stack. So the size of the stack argument + data is 20. */ +#define STACK_ARGUMENTS_SIZE 20 +#else +#define STACK_ARGUMENTS_SIZE 64 +#endif + extern void abort(void); void foo(char *name, double d, double e, double f, int g) @@ -22,7 +31,7 @@ void foo(char *name, double d, double e, void bar(char *name, ...) { - __builtin_apply(foo, __builtin_apply_args(), 64); + __builtin_apply(foo, __builtin_apply_args(), STACK_ARGUMENTS_SIZE); } int main(void)