https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423
--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Martin Jambor <jamb...@gcc.gnu.org>: https://gcc.gnu.org/g:7375909e9d9e7de23acb4b1e0a965d8faf1943c4 commit r16-2347-g7375909e9d9e7de23acb4b1e0a965d8faf1943c4 Author: Martin Jambor <mjam...@suse.cz> Date: Fri Jul 18 12:42:11 2025 +0200 tree-sra: Fix grp_covered flag computation when totally scalarizing (PR117423) Testcase of PR 117423 shows a flaw in the fancy way we do "total scalarization" in SRA now. We use the types encountered in the function body and not in type declaration (allowing us to totally scalarize when only one union field is ever used, since we effectively "skip" the union then) and can accommodate pre-existing accesses that happen to fall into padding. In this case, we skipped the union (bypassing the totally_scalarizable_type_p check) and the access falling into the "padding" is an aggregate and so not a candidate for SRA but actually containing data. Arguably total scalarization should just bail out when it encounters this situation (but I decided not to depend on this mainly because we'd need to detect all cases when we eventually cannot scalarize, such as when a scalar access has children accesses) but the actual bug is that the detection if all data in an aggregate is indeed covered by replacements just assumes that is always the case if total scalarization triggers which however may not be the case in cases like this - and perhaps more. This patch fixes the bug by just assuming that all padding is taken care of when total scalarization triggered, not that every access was actually scalarized. gcc/ChangeLog: 2025-07-17 Martin Jambor <mjam...@suse.cz> PR tree-optimization/117423 * tree-sra.cc (analyze_access_subtree): Fix computation of grp_covered flag. gcc/testsuite/ChangeLog: 2025-07-17 Martin Jambor <mjam...@suse.cz> PR tree-optimization/117423 * gcc.dg/tree-ssa/pr117423.c: New test.
