From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 18A663858C2A for ; Tue, 5 Dec 2023 12:44:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18A663858C2A Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 18A663858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701780258; cv=none; b=i432JB17g9hj0BYsq4UgL+eRjiemdd+KAmtuZ8qxknO4IbR6OVo7Y76erak8Ukp6pqcIH9plxgoB26vOBNuWLG2EN21UDPzxBcxF3FeCeAqxaxmLhX9ITqRRt9RTSUVSouVZWSIpBo7GPnGJdBRVtuib3GT2LJnuJy4c22io0O0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701780258; c=relaxed/simple; bh=hwNyqawlytECvHzJ0bgeRaGboeP70XtH72Y7KITr6qw=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=XlRKsT6oUOirT6wHe7iJObPE3e2LYso2JjGsoToFRTfGPwcGcz9QXG+gP9CDhXglaRbWpFzGUE5c4AA+d+zlW0mH7fmj7smGzMuY+JfPlOufkqDLBhwUuyW4v7aR+u5hfn6nYcgN4dApuY87JBXiC+iI6JJjcEnoecmdlqDp7+U= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1701780254; bh=hwNyqawlytECvHzJ0bgeRaGboeP70XtH72Y7KITr6qw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=kqZP3iilgvrgfO4Mi+ORkW7u0TGVSsmcu3YGVubub63ccsCz8LNkRghbPvXF/SnZe HVZFXWwdZd6b9MMGicgWILEm4ly31j9jePID9DG3S+WePT1KOInqgmc+WyP9rPsQ14 ySbjENc+7qhGxBDIEhGIxq3Zcp9k5DzpRHq1te8I= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 23C9166D12; Tue, 5 Dec 2023 07:44:12 -0500 (EST) Message-ID: <4f4b78a06d9b677fa21964f652cc60a05cf161bb.camel@xry111.site> Subject: Re: [PATCH v1] LoongArch: Modify the check type of the vector builtin function. From: Xi Ruoyao To: chenxiaolong , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn, chenglulu@loongson.cn Date: Tue, 05 Dec 2023 20:44:10 +0800 In-Reply-To: References: <20231204121433.54245-1-chenxiaolong@loongson.cn> <60954f58a9de3494d75899e6dd5cdff7ca2685de.camel@xry111.site> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 2023-12-05 at 17:21 +0800, chenxiaolong wrote: > According to your suggestion, the check of the built-in function was modi= fiedin the simd_correctness_check.h file, and the types of the actual param= eters > of the built-in function were inconsistent with those of the formal param= eters. > The problems with the GCC regression test are as follows: >=20 > ... > note: expected 'const void *' but argument is of type '__m128i' > error: incompatible type for argument 3 of 'ASSERTEQ_64' > ... >=20 > The reason is that the types used in __m{128i,128,128d} are defined in > the vector header file (lsxintrin.h or lasxintrin.h), and their basic > types do not match the parameter types corresponding to the functions. Ouch. I forgot that we are passing vectors themselves to ASSERTEQ_64, not the pointers. Now I come up with this: #include #include #include static inline void dump (const void *_ptr, int size, const char *name) { const char *ptr =3D (const char *)_ptr; printf("%s:", name); for (int i =3D 0; i < size; i++) printf(" %02hhx", ptr[i]); putchar('\n'); } template static inline void assert_eq (const U &res, const V &ref, int line) { static_assert(sizeof (res) =3D=3D sizeof (ref)); if (!memcmp (&res, &ref, sizeof(ref))) return; dump (res, sizeof (res), "res"); dump (ref, sizeof (ref), "ref"); } int main() { float x[4] =3D {}; int y[4] =3D {}; assert_eq(x, y, __LINE__); } This is C++, not C. But IMO we can port the tests to C++ anyway. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University