From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B21DC3858C24; Fri, 22 Mar 2024 08:18:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B21DC3858C24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711095493; bh=kEuJJkLF8cyq9tlwVZ+szuSxe55AWHKfW1L1TRl1UtI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JUDz42SbXeAe+wLXukYsfK85C/q6Lc5+dSdObPUNVB6rQituIgO6BFBQFUCM/Pwr9 sdptg/kxTuSeqzaaAcSirMpv9bSL6j/XmTqLi/uGGTy7haoGNKbgYXTNRKFPSGrmbv VQ5ABGi6AY1OoqvHpJpR+igejR4GlHosJ2Syj6e8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e Date: Fri, 22 Mar 2024 08:18:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 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=3D111683 --- Comment #20 from Jakub Jelinek --- That is true. I've been also wondering whether e.g. for the pr71083.c case= we couldn't just look through all COMPONENT_REFs of the DR_REF (and maybe ARRAY_REFs with constant indexes) and check type size of the aggregate it i= s in against the size. That could perhaps fix the predcom of pr71083.c, because= it is a 24-bit bitfield in 4 byte structure. Will you take this over, or should I tweak my patch? Note, statistics I've gathered with the above posted patch was that the pat= ch did something in /home/jakub/src/gcc/gcc/testsuite/c-c++-common/torture/pr101636.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr32399.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/autopar/pr69109-2.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/graphite/pr71575-2.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/loop-versioning-6.c f1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-1.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-2.c main but only changed the generated code in the last 2 (those are intentional). The older patch with wi::multiple_of_p affected /home/jakub/src/gcc/gcc/testsuite/c-c++-common/torture/pr101636.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr32399.c f /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/execute/pr71083.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.dg/autopar/pr69109-2.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/graphite/pr71575-2.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/loop-versioning-6.c f1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-1.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-2.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/pr112736.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/pr68379.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr87022.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr101445.c foo /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr68502-2.c reset_nodes /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr81740-2.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/vect-avg-16.c f /home/jakub/src/gcc/gcc/testsuite/g++.dg/vect/pr95297.cc test and changed code generation of the 2 expected tests and pr71083.c. All this statistics was solely from make check-gcc check-g++.=