From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 22D5A385660A for ; Tue, 30 May 2023 15:44:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 22D5A385660A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-973f78329e3so469276066b.3 for ; Tue, 30 May 2023 08:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1685461438; x=1688053438; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y2xpjSFLmOLKL5VSp3YZTtYmbh8fKdqSS2XQBXF7VCA=; b=jETANZS2ctWNzlZ5XxVEyxgYiFhpreBn7K91Y65WFrys21lMzhtdKyRYMlmNu+Z9rv njwAx91wlD3n4LSBU8MU34Sk+kcu6aVGO4SIhzQTx1Q5sTU0rgoNKohh79Yrwq5YSHIz QHVKvASCMASdAjbPMU2QllWJlBD2GLr9HjyQ42YiSwJXfuIIBHZoUxLaMZZZhU+N8A7C GOePIZx3HFrkhWVVMbIxBk3Ff2TICPY/6sxEhsIRh4V1SURervWdVTiDwXav/moyAEau m67Ou/sotgOgxk1T0H06j0VlDLPenzEu1JxTjVfKu/5lAAL7LwjvoJedeASQbOusKC7f b3WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685461438; x=1688053438; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y2xpjSFLmOLKL5VSp3YZTtYmbh8fKdqSS2XQBXF7VCA=; b=BAF2Rrn2t0oi3tjPJ4VyNlfxuWhChL5T5OXSPF9GzLTEunPnDyt6MkhdemDg878cNF MpHogwWD1n7+SoInbGzpLhY+mZKrjJiTUfcXZmC26HkbFA9qx0sACXPHns76Z9U8JxLq PNtcKDk9dmtLOhavQiYolPRRZZErLIsiYeIobtqsWb44rJQBXCscSnrBz0GQpTONDpE2 QYibWt/+YNDLMyUQCv3WqjTG8k785wGudf27BfC/3dRfpiPjA0q+kIQQyl9GDfrBEAIo 8/w/TFPyKsQdY9fMk5g3AQ6165/uPNYWQMZndzvj5Ucz+aMQ2u9P2YoQfzyD7L2eYuep 9Llw== X-Gm-Message-State: AC+VfDz1zR/ZtnMyemBXe8LaAQuGGVr2jexRcsE+N2ZYNuI+x6GAziQv DhvihrSlN9DuzQpwS4wEcoxbNMX7bMm/CHNKmXwdP8KzjPO878OUqEdnmQ== X-Google-Smtp-Source: ACHHUZ5Ekb2/tef1b3J5rQeoHF3o4k0kuMJ/Te9Hr9OveCf+LVxoO/Mm8I4O1hlixl2QzlRCKudU0F8jfF+xWPlNLTY= X-Received: by 2002:a17:907:d15:b0:971:2ead:e161 with SMTP id gn21-20020a1709070d1500b009712eade161mr2979812ejc.6.1685461437770; Tue, 30 May 2023 08:43:57 -0700 (PDT) MIME-Version: 1.0 References: <20230523144145.315887-1-christophe.lyon@linaro.org> In-Reply-To: From: Christophe Lyon Date: Tue, 30 May 2023 17:43:52 +0200 Message-ID: Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic To: kyrylo.tkachov@arm.com Cc: gcc-patches@gcc.gnu.org, Stamatis Markianos-Wright Content-Type: multipart/alternative; boundary="00000000000048048205fceb1248" X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: --00000000000048048205fceb1248 Content-Type: text/plain; charset="UTF-8" Ping? On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright < stam.markianos-wright@arm.com> wrote: > > On 23/05/2023 15:41, Christophe Lyon 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. > > Thank you for spotting this! I think this fix is needed on all of > GCC12,13,trunk btw (it should apply cleanly) > > > > > > 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 > > 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); > > } > --00000000000048048205fceb1248--