From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 08E553858D32; Mon, 23 Jan 2023 17:42:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08E553858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674495757; bh=tOaY7IaesbBb0pRHFdSGeR3UNH8ekm5oOHFTmZR6xpQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Gr3MOJW+SEglfwCnYlC9dotCyyPjp71ZPVVbjIDlLcrvWaH9C+XLU8kj9MgxGrO+k TG79ZiWZHxySMiW8bvQF/cyaybvwM02AJycTQGJB7tTdDbUV2gfkw13oXdMfCMYfZz V3at1bck/7omJbYTrCOlZfBuTPBo/uLwa3v35+To= From: "kungfujesus06 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging Date: Mon, 23 Jan 2023 17:42:36 +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: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: kungfujesus06 at gmail dot com 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=3D108498 --- Comment #11 from Adam Stylinski --- (In reply to Andrew Pinski from comment #9) > The only thing is memcpy could be broken ... >=20 > I can't find anything wrong with the generated code. >=20 >=20 > 100007cc: 38 a0 00 44 li r5,68 > ... > 100007d8: 3c 00 02 00 lis r0,512 > 100007dc: 60 00 ff 03 ori r0,r0,65283 > 100007e0: 78 00 07 c6 sldi r0,r0,32 > 100007e4: 64 00 00 01 oris r0,r0,1 > 100007e8: 60 00 02 03 ori r0,r0,515 > ... > 100007fc: 38 81 00 74 addi r4,r1,116 > ... > 1000080c: 7c 7f 1b 78 mr r31,r3 > ... > 10000818: f8 01 00 74 std r0,116(r1) > ... > 1000082c: 4b ff fd 15 bl 10000540 > <0000003b.plt_call.memcpy@@GLIBC_2.3> > ... >=20 >=20 >=20 >=20 >=20 > On the main side: > addi %r3,%r1,116 > ld %r9,-28688(%r13) > std %r9,184(%r1) > li %r9,0 > bl emit_test > lwz %r4,124(%r1) It's possible's a glibc bug and clang avoids it by simply not needing it bu= t it seems doubtful a small memcpy like this would have an issue that didn't sho= w up until now. It seems like if it did need a memcpy, GCC would invoke it's builtin for a struct like like this rather than call into a library functio= n.=20 Is there a compilation flag I can invoke to rule that out? Like some sort = of "only builtins"?=