https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127752

--- Comment #9 from Yongqiang Tian <yqtian668 at gmail dot com> ---
Thank you for the suggestions.

I have attached a revised prototype that removes the recursive type walk. It
repurposes an unused generic type bit as `TYPE_CONTAINS_VOLATILE_SUBOBJECT`.
The bit is set monotonically during layout: `place_field` propagates it from a
directly volatile field or from an aggregate field type that already contains a
volatile subobject, and array types inherit it from their element type.

The property is also copied to type variants, preserved by LTO streaming and
C++ module duplicate definitions, and handled when `ipa-free-lang-data` creates
incomplete copies. `ipa.cc::process_references` therefore only needs an O(1)
bit test.

I kept the existing C-specific `C_TYPE_FIELDS_VOLATILE` behavior unchanged
because it records a frontend-specific property and does not provide the
transitive, cross-language property needed by IPA and LTO.

One detail I found while testing was that C++ uses its own class-layout path,
so setting the bit only in the generic `RECORD_TYPE` case did not cover C++.
Propagating it through the shared `place_field` path covers both the C and C++
cases without a recursive walk.

The following checks pass with the revised prototype:

- C compiler selftests: 7,665,891 passes
- C++ compiler selftests: 7,665,915 passes
- focused C, C++, whole-program and LTO checks
- nested record, array and union cases
- negative controls for non-volatile fields and pointer fields
- targeted C++ DejaGNU test: 6 expected passes
- targeted two-translation-unit LTO test: 3 expected passes
- `contrib/check_GNU_style.sh` and `git diff --check`

The clean compiler still demonstrates the original failure, while the revised
compiler preserves the volatile loads. I have not yet run a full bootstrap and
regression test.

Does this placement and propagation of the generic type bit match what you had
in mind? If so, I can proceed with the full testing and prepare the formal
mailing-list patch.

Reply via email to