From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 04DC73858D33; Fri, 24 May 2024 01:52:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 04DC73858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1716515523; bh=ldfQeoMiZp40eUpQo1rJJG1YO6KaHrecNYX4vWWROCM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h9ziVOLPDAsoNmNuswqOJKWnNoTx+jlIzdnTdXF25kTfExjee17Pj0eFlY6FQXaUW UrPENQ2FUT5srcbE05EBF2u4ej+3jzxf5BGxNTnW1vm8Hwa7pcvtjpw1ntSVtuwIFU 3lWpl489apiaJIoFL7mqzXEuh0brKk0zsshfI1ws= From: "liuhongt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs Date: Fri, 24 May 2024 01:52:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: liuhongt at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114148 --- Comment #4 from Hongtao Liu --- (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #3) > To investigate further, I've added comparison functions to a reduced > version of pr106010-7b.c, with >=20 > void > cmp_epi8 (_Complex unsigned char* a, _Complex unsigned char* b) > { > for (int i =3D 0; i !=3D N; i++) > if (a[i] !=3D b[i]) > { > printf ("cmp_epi8: i =3D %d: a[i].r =3D %x a[i].i =3D %x b[i].r =3D %x b= [i].i =3D > %x\n", > i, __real__ a[i], __imag__ a[i], __real__ b[i], __imag__ b[i]); > } > } >=20 > This shows (when using _Complex unsigned char since on Solaris, char is > signed by default) >=20 > cmp_epi8: i =3D 76: a[i].r =3D 0 a[i].i =3D 0 b[i].r =3D 88 b[i].i =3D 33 > cmp_epi8: i =3D 77: a[i].r =3D 0 a[i].i =3D 0 b[i].r =3D 6 b[i].i =3D 8 > cmp_epi8: i =3D 80: a[i].r =3D 0 a[i].i =3D 0 b[i].r =3D 3 b[i].i =3D 0 >=20 > I've also noticed that the test result depends on the implementation of > malloc used: >=20 > * With Solaris libc malloc, libmalloc, and watchmalloc, the test aborts. >=20 > * However, when using one of libbsdmalloc, libmapmalloc, libmtmalloc, or > libumem, the test works. >=20 > However, ISTM that the test is simply bogus: in avx_test >=20 > * epi8_src, epi8_dst are allocated with malloc, buffer contents undefined >=20 > * epi8_dst is cleared >=20 > * epi8_dst is initialized from p_init >=20 > * in foo_epi8, epi8_src[0] (an undefined value) is copied into first N > elements of epi8_dst >=20 > * epi8_dst is compared to epi8_src (with the remaining members of epi8_src > still undefined) uoops, does below patch fix the testcase on Solaris/x86? memcpy (pd_src, p_init, 2 * N * sizeof (double)); - memcpy (ps_dst, p_init, 2 * N * sizeof (float)); - memcpy (epi64_dst, p_init, 2 * N * sizeof (long long)); - memcpy (epi32_dst, p_init, 2 * N * sizeof (int)); - memcpy (epi16_dst, p_init, 2 * N * sizeof (short)); - memcpy (epi8_dst, p_init, 2 * N * sizeof (char)); + memcpy (ps_src, p_init, 2 * N * sizeof (float)); + memcpy (epi64_src, p_init, 2 * N * sizeof (long long)); + memcpy (epi32_src, p_init, 2 * N * sizeof (int)); + memcpy (epi16_src, p_init, 2 * N * sizeof (short)); + memcpy (epi8_src, p_init, 2 * N * sizeof (char)); >=20 > Why on earth would the rest of epi8_dst and epi8_src be identical if > epi8_src was never initialized? Guess, epi8_src is all zero, and epi8_dst if set as epi8_src[0] by foo_epi8= .=