From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4319B385117C; Fri, 26 Aug 2022 18:38:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4319B385117C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661539113; bh=2voOd3rbqFcsWsZ4nueqi3p789NsNmdvCd5WHAVwag0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IUeyjMWhhEwficUhQjFOpN8ib3GtdbNDnSr8Z2J25xFhlg8Ty1OUJJDrEC/WllXC7 526o+x81CX4UUZTyr8ei/2efeypGiq+8j2/9nWTvDhd8X0NFlqVLSkTZ8R8xb9ZsD2 jIlTX6K5H+nfti2V5ViDAEb2y8kSrPEb38HwbokU= From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106755] Incorrect code gen for altivec intrinsics with constant inputs Date: Fri, 26 Aug 2022 18:38:33 +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: 12.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: blocker X-Bugzilla-Who: bergner at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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=3D106755 --- Comment #4 from Peter Bergner --- (In reply to Andrew Pinski from comment #3) > So yes there is aliasing violation as you do the store as vui128_t aka > "__vector unsigned __int128" (which has the same aliasing set) as "__int1= 28" > but then do the load from it as vui32_t aka "__vector unsigned int vui32_= t" > (which is the same aliasing set as int).=20 Yes, I came to the same conclusion and sent Steve a patch offline that fixes the issue. > -Wstrict-aliasing=3D3 might warn about this case I can't remember exactly= of > the levels of the options but the -Wstrict-aliasing warnings are always n= ot > going to happen, sometimes it is easier to read the code. Ah, I didn't realize we could increase the warning level. Cool! It seems -Wstrict-aliasing=3D2 is enough to catch the problem: gcc -O3 -Wall -c -fmessage-length=3D0 -mcpu=3Dpower8 -mtune=3Dpower8 -Wstrict-aliasing=3D2 -m64 ../src/vec_bug6.c ../src/vec_bug6.c: In function =E2=80=98test_muludq=E2=80=99: ../src/vec_bug6.c:969:45: warning: dereferencing type-punned pointer will b= reak strict-aliasing rules [-Wstrict-aliasing] 969 | k =3D (vui32_t) test_vec_muludq((vui128_t* )&l, (vui128_t)i, (vui128_t)j); ...=