From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 790203858D28; Mon, 4 Oct 2021 19:19:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 790203858D28 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102571] FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test Date: Mon, 04 Oct 2021 19:19:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: component 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 19:19:13 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102571 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Component|libgomp |tree-optimization --- Comment #1 from Jakub Jelinek --- Seems like tree DSE bug to me. We have before dse1: D.2119 =3D 0.0; MEM [(long double *)&D.2119 + 10B] =3D {}; __builtin_GOMP_atomic_start (); _58 =3D MEM[(long double * {ref-all})&ld]; D.2118 =3D _58; MEM [(long double *)&D.2118 + 10B] =3D {}; _13 =3D __builtin_memcmp (&D.2118, &D.2119, 16); where D.2119 and D.2118 have long double type. But dse1 says: Deleted redundant store: MEM [(long double *)&D.2119 + 10B] =3D= {}; and removes that store, but that isn't really redundant, because long double has padding bits. For OpenMP, perhaps I could get away around this and if I prove the non-pad= ding bits in the type are contiguous followed by padding bits the boundary betwe= en the two is on a byte boundary, I could optimize the __builtin_clear_padding (&arg1); __builtin_clear_padding (&arg2); x =3D __builtin_memcmp (&arg1, &arg2, 16); // or 12 for ia32 into just x =3D __builtin_memcmp (&arg1, &arg2, 10); (and I'll probably implement it tomorrow). But it won't really help libstdc++, which will once the https://gcc.gnu.org/pipermail/libstdc++/2021-September/053210.html patch is= in, use __builtin_clear_padding + __atomic_*, most likely in different inline functions and will almost certainly suffer from this. In val =3D 0; MEM ... [&val + ...] =3D {}; the second stmt is only redundant if the type doesn't have any padding bits= ... I guess gimple-fold.c could provide an even cheaper helper whether the type= has padding bits than what is currently provided. Then there is the question on unions, __builtin_clear_padding needs to be conservative for unions and only clear bits that are proven to be padding in all union members. But to disable the DSE optimization, we probably need to ask a different question, instead of "does the type have any padding bits t= hat would be cleared by __builtin_clear_padding?" ask "can the type have any padding bits?" where for unions the answer would be true if any member has = them rather than if all the members have them in the same positions.=