https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127752
--- Comment #13 from Yongqiang Tian <yqtian668 at gmail dot com> --- Thanks a lot for the guidance. I investigated this further, including the `-fwhole-program` and static-variable cases. I agree that marking every declaration whose type contains a volatile subobject would be too broad: it could retain an object even when only its non-volatile members are accessed, or when it is not accessed at all. I tried a narrower change at RTL expansion instead. When expanding the base of an actual volatile inner reference, the patch uses `EXPAND_MEMORY`, so the access must read the object itself. This does not otherwise prevent the object from being optimized. I tested the attached prototype on current master, revision `75cc549c46188b02b736d2d0e4dfdbf6031293c3`: - the original cross-TU LTO reproducer retains the volatile load; - the same is true with `-fwhole-program`; - a single-TU reproducer with a static object also retains the load; - an object whose non-volatile member alone is accessed can still be folded away; - an entirely unused object can still be removed. I also added an LTO regression test that checks for the volatile `mem/v` access in the LTRANS expand dump. The test fails with the unmodified compiler and passes with the change. The focused tests report 4 expected passes, and the patch passes `check_GNU_style.sh` and `git diff --check`. This does not try to resolve the broader question of when the C frontend should set `DECL_PRESERVE_P`; it only addresses the confirmed loss of the volatile access during RTL expansion. I may still be misunderstanding the intended frontend-side solution, so I would appreciate your advice on whether this narrower scope looks appropriate. I have not run the full bootstrap and regression suite yet. If this direction is reasonable, I can do that next and submit the patch to gcc-patches. Thanks a lot, again!
