From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 877423858C52; Fri, 14 Oct 2022 16:53:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 877423858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1665766407; bh=E72qwSHr1LwU0pOgB+Dmz239GmAN4sXrs01LLVjuTxU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YbRvIZ9UWszJcBDXAARQF9DKH/RonL2qZuHGth/FOfgVzxGyJFV1oVcVwrojnqQ37 2r2dBmE7LE8pqc5NcGz1qTVe4rD/X0cIuQkwFmdjU3Ozj2ewxfUFl2FlENsTEPFNxv /R7QTu9UTkcc0/o8+9EKwBeSKQfwqXqj4O6uNHg0= From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107206] Bogus -Wuninitialized in std::optional Date: Fri, 14 Oct 2022 16:53:25 +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.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: NEW 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=3D107206 --- Comment #5 from Martin Jambor --- I believe this is fallout from the fix to PR 92706 where we started propagating accesses across assignments also from LHS to RHS and because everything is totally flow-insensitive, we have an access representing: MEM[(union _StorageD.10576 *)&D.11678]._M_valueD.10616 =3D 1; which gets propagated across: zD.11527.yD.11476.oD.11384 =3D D.11678; but this then triggers the LHS->RHS propagation across: MEM[(struct YD.10174 *)&zD.11527].oD.11384 =3D MEM[(const struct YD.10174 &)&D.11546].oD.11384; So another reason to re-invent SRA from scratch. Apart from that, I don't have a good solution except for adding another flag to mark accesses that are result of LHS->RHS propagation and ignore them if their base did not get totally scalarized because in the PR they were added basically to prevent bad total scalarization. But of course it is rather another band-aid than a real fix, but it seems to work for this case: diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc index 1a3e12f18cc..6cbeddfc548 100644 --- a/gcc/tree-sra.cc +++ b/gcc/tree-sra.cc @@ -260,6 +260,9 @@ struct access /* Should TREE_NO_WARNING of a replacement be set? */ unsigned grp_no_warning : 1; + + /* Result of propagation accross link from LHS to RHS. */ + unsigned grp_result_of_prop_from_lhs : 1; }; typedef struct access *access_p; @@ -2532,6 +2535,9 @@ analyze_access_subtree (struct access *root, struct access *parent, if (allow_replacements && expr_with_var_bounded_array_refs_p (root->expr= )) allow_replacements =3D false; + if (!totally && root->grp_result_of_prop_from_lhs) + allow_replacements =3D false; + for (child =3D root->first_child; child; child =3D child->next_sibling) { hole |=3D covered_to < child->offset; @@ -2959,6 +2965,7 @@ propagate_subaccesses_from_lhs (struct access *lacc, struct access *racc) struct access *new_acc =3D create_artificial_child_access (racc, lchild, norm_offset, true, false); + new_acc->grp_result_of_prop_from_lhs =3D 1; propagate_subaccesses_from_lhs (lchild, new_acc); } else=