[Bug c++/124399] [reflection] meta::annotations_of issue
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Mar 10 20:28:14 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124399
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:9c483886957cac7016dc404c2b6aab2ae94574a9
commit r16-7992-g9c483886957cac7016dc404c2b6aab2ae94574a9
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Mar 10 21:27:10 2026 +0100
c++: For reflection comparison of annotations compare TREE_VALUE [PR124399]
https://eel.is/c++draft/meta.reflection#annotation-4
testcase also contains
[[=1]] int x, y;
static_assert(annotations_of(^^x)[0] == annotations_of(^^y)[0]);
so in case of an annotation shared by multiple declarations we need
to compare the TREE_VALUE of the attributes (which is shared in that
case) rather than the TREE_LIST with that TREE_VALUE and TREE_PURPOSE
being "internal ":"annotation ".
For mangling we already handle it right:
if (eval_is_annotation (h, kind) == boolean_true_node)
{
strcpy (prefix, "an");
if (TREE_PURPOSE (TREE_VALUE (h)) == NULL_TREE)
TREE_PURPOSE (TREE_VALUE (h))
= build_int_cst (integer_type_node, annotation_idx++);
return TREE_PURPOSE (TREE_VALUE (h));
}
so the annotation index is stored on TREE_PURPOSE of the TREE_VALUE,
so in shared annotation like the above it will have the same index
in both cases.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
When I was adding further tests for this, I've noticed that we don't
handle correctly
[[=1]] int x [[=2]], y [[=3]];
because the attributes list which is shared is clearly added as a shared
tail of the other attributes. For now this is commented out in the
test, will try to deal with it somehow incrementally.
2026-03-10 Jakub Jelinek <jakub@redhat.com>
PR c++/124399
* reflect.cc (compare_reflections): For REFLECT_ANNOTATION, compare
TREE_VALUE of lhs and rhs instead of lhs and rhs.
* g++.dg/reflect/annotations12.C: Add further tests.
More information about the Gcc-bugs
mailing list