On 3/18/26 4:19 AM, Thomas Berger wrote:
Previously, finish_member_declaration prepended non-type members and
appended TYPE_DECLs to TYPE_FIELDS separately, so that the TYPE_DECLs
always appeared after all non-type members regardless of their decleration
order.

Store all members in declaration order instead and update the places,
that relied on the old layout.

gcc/analyzer/ChangeLog:

        * region-model.cc (struct_or_union_with_inheritance_p): Skip
        leading TYPE_DECL nodes before checking for base class field.

gcc/cp/ChangeLog:

        * class.cc (unreverse_member_declarations): Use nreverse for both
        CLASSTYPE_DECL_LIST and TYPE_FIELDS.
        * decl.cc (reshape_init_class): Guard anonymous aggregate field
        search with FIELD_DECL check.
        * name-lookup.cc (fields_linear_search): Return first non-type
        match immediately; fall back to TYPE_DECL if no non-type is found.
        * parser.cc (remove_dummy_lambda_op): Search chain for dummy
        operator instead of assuming it is the TYPE_FIELDS head.
        * semantics.cc (finish_member_declaration): Always prepend to
        FIELD_DECL; remove separate handling for TYPE_DECL.

Signed-off-by: Thomas Berger <[email protected]>
---
  gcc/analyzer/region-model.cc |  4 ++++
  gcc/cp/class.cc              | 24 +-----------------------
  gcc/cp/decl.cc               |  3 ++-
  gcc/cp/name-lookup.cc        | 19 +++++++++++++++++--
  gcc/cp/parser.cc             | 20 +++++++++++---------
  gcc/cp/semantics.cc          | 20 ++------------------
  6 files changed, 37 insertions(+), 53 deletions(-)

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 4a6f5b4800c..75241f23bb1 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -4116,6 +4116,10 @@ static bool
  struct_or_union_with_inheritance_p (tree struc)
  {
    tree iter = TYPE_FIELDS (struc);
+
+  while (iter && TREE_CODE (iter) == TYPE_DECL)

I still think this should be != FIELD_DECL, rather than == TYPE_DECL.

Other than that this patchset looks great for GCC 17, thanks!

Unfortunately it's not suitable for GCC 16 at this point since this isn't a regression and the change affects non-experimental code.

Jason

Reply via email to