On Sun, Mar 15, 2026 at 12:49:07PM -0700, Andrew Pinski wrote:
> After r16-6808-g4b0e94b394fa38, added was a loop around
> attributes looking for an annotation attribute but
> does not take into account the attribute might be
> an error mark, so there is an ICE when trying to access
> the get_attribute_name. This fixes the issue by breaking
> out of the loop if the attribute is an error.
>
> Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>
> PR c++/124307
>
> gcc/cp/ChangeLog:
>
> * parser.cc (cp_parser_base_specifier): Break from the loop
> if an attribute is an error mark.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/alignas24.C: New test.
>
> Signed-off-by: Andrew Pinski <[email protected]>
Using error_operand_p on something that isn't expression and doesn't
have (meaningful) TREE_TYPE is a weird.
Furthermore, I think error_mark_node can't appear as TREE_CHAIN of
something else in the list (see e.g. attr_chainon), so it is solely
whether std_attrs is error_mark_node or not.
So I think it would be easier to change
if (std_attrs != NULL_TREE)
to
if (std_attrs != NULL_TREE && std_attrs != error_mark_node)
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -31835,6 +31835,8 @@ cp_parser_base_specifier (cp_parser* parser)
> tree *pannotations = &annotations;
> for (tree attr = std_attrs; attr; attr = TREE_CHAIN (attr))
> {
> + if (error_operand_p (attr))
> + break;
> if (annotation_p (attr))
> {
> *pannotations = attr;
Jakub
