From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C19B43858D39; Mon, 23 Oct 2023 12:36:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C19B43858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1698064603; bh=ArZzqZctb2MOdTmf+gciw9aG+urfzM5S1/Choujf6w4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VTOjs9PkeoheLXx5PlBVEmXTeAt7RylcrMu/8cINc0odoFuGSgrqkkekW04rURGmr wvkiKdZ3wrnxQR4Ta3XzutAV9hDx/cemf7rfRuH03BJhtkn4Vc5UI0j9tb4qqyx4LX 56aV/9xQamFaRaZSjhMv12nSNj9gLGjXJKBzlTSg= From: "matz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3 Date: Mon, 23 Oct 2023 12:36:42 +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: 13.2.0 X-Bugzilla-Keywords: needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D111591 Michael Matz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz at gcc dot gnu.org --- Comment #28 from Michael Matz --- (In reply to Richard Biener from comment #27) > (In reply to Kewen Lin from comment #26) > > Thanks for the clarification! Is it possible to update the alias set fo= r the > > indirect accesses as well? since we know the address is originally taken > > from one coalesced decl (also update its propagated ones). That's not generally possible, the address-taking and the actual access mig= ht be separated by arbitrary obfuscating code: char *p =3D &x; char *p2 =3D get_some_pointer(p); *p2 =3D ... Here p2 may, or may not, point to x. So we'd need to be fairly conservative here ... > I suppose we could record a bitmap of all decls participating in any > coalescing, check whether a MEM could possibly refer to any of them > via the points-to API ... which the points-to API of course will be. > and then force alias-set zero for those. So that will work. But I wonder if the result then won't be that essential= ly all of the mem accesses will get alias set zero, at least if there was any coalescing. At that point we may also bite the bullet and just do away with any TBAA alias sets in RTL at all. > We > could also try to do sophisticated analysis to make assigning a new > alias-set for each coalesce group work, merging groups when there's > indirect accesses that could alias a member of more than a single > group. Question is if the sophistication is worth it.=