From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 315183858D39 for ; Wed, 6 Dec 2023 16:37:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 315183858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 315183858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701880636; cv=none; b=N5wQVNcY70pVCo+o5vW0tsV5K6b+TeWN0U7IhClmjgOABZjlRyF7jfvcsjL//3HoLj5hCgnptwfT6joW1HYYDuEPdT5YVllYweZ5rTndstE8ia36zbirHL1/BjOZ4mbQUMQw5Y0pSgtevFqJiwU6zvBw3CTlRKQ2aHFVLXhoji0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701880636; c=relaxed/simple; bh=6tjYOw8JFX3CuydYWwxkLfueFKBPqKFLr3etrNF7c68=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=V9dl1PVBC7+I26l8c5/4iq9JVg5K3UWEZmvUmicnglRGzCyh4LgdVvehLJM1UUYHoZwtopLrVa6gWY8HbEDtEjCPD4br3fThNWI2NeN3fxcEE7A/K7gM0rQM51Vi5iUZk+NdXyUcTsTBUzuQrC87584tRoJRxoDcLn43AEBcNLs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 68C22153B; Wed, 6 Dec 2023 08:38:00 -0800 (PST) Received: from [10.57.5.1] (unknown [10.57.5.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C06263F762; Wed, 6 Dec 2023 08:37:13 -0800 (PST) Message-ID: <37fd9386-b58a-4842-8485-369bb585fbf1@foss.arm.com> Date: Wed, 6 Dec 2023 16:37:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic Content-Language: en-GB To: Christophe Lyon , gcc-patches@gcc.gnu.org, stam.markianos-wright@arm.com, Kyrylo.Tkachov@arm.com References: <20230523144145.315887-1-christophe.lyon@linaro.org> From: Richard Earnshaw In-Reply-To: <20230523144145.315887-1-christophe.lyon@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3495.1 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sorry, I only just spotted this while looking at something else. On 23/05/2023 15:41, Christophe Lyon via Gcc-patches wrote: > Glibc defines int32_t as 'int' while newlib defines it as 'long int'. > > Although these correspond to the same size, g++ complains when using the 'wrong' version: > invalid conversion from 'long int*' to 'int32_t*' {aka 'int*'} [-fpermissive] > or > invalid conversion from 'int*' to 'int32_t*' {aka 'long int*'} [-fpermissive] > > when calling vst1q(int32*, int32x4_t) with a first parameter of type > 'long int *' (resp. 'int *') > > To make this test pass with any type of toolchain, this patch defines > 'word_type' according to which libc is in use. > > 2023-05-23 Christophe Lyon > > gcc/testsuite/ > * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c: > Support both definitions of int32_t. > --- > .../mve_intrinsic_type_overloads-int.c | 28 ++++++++++--------- > 1 file changed, 15 insertions(+), 13 deletions(-) > > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > index 7947dc024bc..ab51cc8b323 100644 > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > @@ -47,14 +47,22 @@ foo2 (short * addr, int16x8_t value) > vst1q (addr, value); > } > > -void > -foo3 (int * addr, int32x4_t value) > -{ > - vst1q (addr, value); /* { dg-warning "invalid conversion" "" { target c++ } } */ > -} > +/* Glibc defines int32_t as 'int' while newlib defines it as 'long int'. > + > + Although these correspond to the same size, g++ complains when using the > + 'wrong' version: > + invalid conversion from 'long int*' to 'int32_t*' {aka 'int*'} [-fpermissive] > + > + The trick below is to make this test pass whether using glibc-based or > + newlib-based toolchains. */ > > +#if defined(__GLIBC__) > +#define word_type int > +#else > +#define word_type long int > +#endif GCC #defines __INT32_TYPE__ for this and should be more reliable than trying to detect one specific library implementation. Did you try that? > void > -foo4 (long * addr, int32x4_t value) > +foo3 (word_type * addr, int32x4_t value) > { > vst1q (addr, value); > } > @@ -78,13 +86,7 @@ foo7 (unsigned short * addr, uint16x8_t value) > } > > void > -foo8 (unsigned int * addr, uint32x4_t value) > -{ > - vst1q (addr, value); /* { dg-warning "invalid conversion" "" { target c++ } } */ > -} > - > -void > -foo9 (unsigned long * addr, uint32x4_t value) > +foo8 (unsigned word_type * addr, uint32x4_t value) > { > vst1q (addr, value); > } R.