[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.5 --- Comment #15 from Jakub Jelinek --- Fixed also for 13.5.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312
--- Comment #14 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:dea83cfd1228a14aca904cf4091b7ccb74d6
commit r13-10199-gdea83cfd1228a14aca904cf4091b7ccb74d6
Author: Jakub Jelinek
Date: Fri Feb 6 20:26:01 2026 +0100
Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own
TYPE_MAIN_VARIANT [PR101312]
I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for
PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself. For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its
TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
return build_type_attribute_qual_variant (ttype, attribute,
TYPE_QUALS (ttype));
so pass the quals of the type to it. If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.
Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL. The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold. We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT
(type
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).
The following patch changes get_alias_set and tree.cc to verify that
instead. For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL). verify_type already checks that though.
I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.
2026-02-06 Jakub Jelinek
PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.
* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.
(cherry picked from commit f210e0bb90970a7fda6cf94e2694ea209eb61a16)
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 --- Comment #13 from Jakub Jelinek --- Fixed also for 14.4.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ad5a033aa32920444a8720904ca8adfee9830db3
commit r14-12406-gad5a033aa32920444a8720904ca8adfee9830db3
Author: Jakub Jelinek
Date: Fri Feb 6 20:26:01 2026 +0100
Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own
TYPE_MAIN_VARIANT [PR101312]
I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for
PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself. For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its
TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
return build_type_attribute_qual_variant (ttype, attribute,
TYPE_QUALS (ttype));
so pass the quals of the type to it. If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.
Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL. The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold. We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT
(type
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).
The following patch changes get_alias_set and tree.cc to verify that
instead. For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL). verify_type already checks that though.
I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.
2026-02-06 Jakub Jelinek
PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.
* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.
(cherry picked from commit f210e0bb90970a7fda6cf94e2694ea209eb61a16)
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 --- Comment #11 from Jakub Jelinek --- Fixed also for 15.3.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312
--- Comment #10 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:edeb14d47a7abf65f15de21c689dd9a6a9a3000d
commit r15-10898-gedeb14d47a7abf65f15de21c689dd9a6a9a3000d
Author: Jakub Jelinek
Date: Fri Feb 6 20:26:01 2026 +0100
Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own
TYPE_MAIN_VARIANT [PR101312]
I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for
PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself. For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its
TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
return build_type_attribute_qual_variant (ttype, attribute,
TYPE_QUALS (ttype));
so pass the quals of the type to it. If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.
Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL. The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold. We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT
(type
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).
The following patch changes get_alias_set and tree.cc to verify that
instead. For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL). verify_type already checks that though.
I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.
2026-02-06 Jakub Jelinek
PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.
* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.
(cherry picked from commit f210e0bb90970a7fda6cf94e2694ea209eb61a16)
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f210e0bb90970a7fda6cf94e2694ea209eb61a16
commit r16-7369-gf210e0bb90970a7fda6cf94e2694ea209eb61a16
Author: Jakub Jelinek
Date: Fri Feb 6 20:26:01 2026 +0100
Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own
TYPE_MAIN_VARIANT [PR101312]
I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for
PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself. For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its
TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
return build_type_attribute_qual_variant (ttype, attribute,
TYPE_QUALS (ttype));
so pass the quals of the type to it. If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.
Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL. The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold. We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT
(type
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).
The following patch changes get_alias_set and tree.cc to verify that
instead. For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL). verify_type already checks that though.
I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.
2026-02-06 Jakub Jelinek
PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.
* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f03e1f3d510e3e42fb85b5269d009f990d1f301 commit r16-7328-g9f03e1f3d510e3e42fb85b5269d009f990d1f301 Author: Jakub Jelinek Date: Thu Feb 5 14:59:12 2026 +0100 Revert c, c++: Use c*_build_qualified_type instead of build_qualified_type from within build_type_attribute As seen in PR123882, this broke more than it fixed, a lot of build_type_attribute_qual_variant including build_type_attribute_variant just pass in TYPE_QUALS (type) as the last argument and for C/C++ when the code pushes the quals to the element type, it will effectively make those unqualified. The PR123882 ICE is then on the array_as_string terrible hack if the FE calls get_aka_type on that, it wants to create qualified attribute variant of that and errors on the restrict qual. So, to fix both PR c/123882 and other unknown regressions caused by PR c/101312 I'm reverting it now. This reverts commit 3d2a91a3767982dde5a37abf45c12c08d4fdbf41.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3d2a91a3767982dde5a37abf45c12c08d4fdbf41 commit r16-7102-g3d2a91a3767982dde5a37abf45c12c08d4fdbf41 Author: Jakub Jelinek Date: Wed Jan 28 09:50:26 2026 +0100 c, c++: Use c*_build_qualified_type instead of build_qualified_type from within build_type_attribute_qual_variant [PR101312] The following testcases ICE in various ways because of the interaction between attributes and C/C++ c*_build_qualified_type behavior on array types and how they affect TYPE_CANONICAL. For array types, C/C++ moves qualifiers to the element type, but when a cv qualified array build that way has an attribute applied to it, we call build_type_attribute_qual_variant and that doesn't have that handling and builds non-qualified version of the array type with qualified element type and puts it as TYPE_CANONICAL of the type with attribute which is a distinct type copy. The following patch adds a langhook, so that even build_type_attribute_qual_variant uses for C/C++ for array types c*_build_qualified_type. There has been already a related langhook lang_hooks.types.copy_lang_qualifiers used solely for C++, so instead of adding another langhook this adds a combined langhook for those two, where C can handle array types specially and otherwise build_qualified_type, while C++ ditto + do the function/method type modifiers propagation as well. Unfortunately there is a terrible array_as_string hack used by some of the middle-end warnings which creates some array type with sometimes an artificial attribute and then has hacks in the c-family type printing to tweak the printed form, and this hack relies on the previous behavior of build_type_attribute_qual_variant where it even for C/C++ kept element type quals unmodified and added normally invalid quals on the array type itself. The patch stops using build_type_attribute_qual_variant for that and instead uses copy_node on the type and adjusts the quals and adds the attribute to the copy and then ggc_frees it. Also it renames the attribute from "array" to "array " to make it clear it is internal attribute users can't specify even in vendor attributes. 2026-01-28 Jakub Jelinek PR c/101312 gcc/ * langhooks.h (struct lang_hooks_for_types): Remove copy_lang_qualifiers. Add build_lang_qualified_type. * langhooks.cc (lhd_build_lang_qualified_type): New function. * langhooks-def.h (lhd_build_lang_qualified_type): Declare. (LANG_HOOKS_COPY_LANG_QUALIFIERS): Remove. (LANG_HOOKS_BUILD_LANG_QUALIFIED_TYPE): Add. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Use LANG_HOOKS_BUILD_LANG_QUALIFIED_TYPE instead of LANG_HOOKS_COPY_LANG_QUALIFIERS. * attribs.cc (build_type_attribute_qual_variant): Use lang_hooks.types.build_lang_qualified_type instead of build_qualified_type and/or build_qualified_type with optional lang_hooks.types.copy_lang_qualifiers call. (attr_access::array_as_string): Use "array " attribute instead of "array". If attribute has been created or intended quals differ from quals of build_array_type, use copy_node and adjust quals and attributes on the copy, print and then ggc_free. gcc/c-family/ * c-pretty-print.cc (c_pretty_printer::direct_abstract_declarator): Look up "array " attribute instead of "array". gcc/c/ * c-tree.h (c_build_lang_qualified_type): Declare. * c-objc-common.h (LANG_HOOKS_BUILD_LANG_QUALIFIED_TYPE): Define. * c-objc-common.cc (c_build_lang_qualified_type): New function. gcc/cp/ * cp-tree.h (cxx_build_lang_qualified_type): Declare. * cp-objcp-common.h (LANG_HOOKS_COPY_LANG_QUALIFIERS): Remove. (LANG_HOOKS_BUILD_LANG_QUALIFIED_TYPE): Define. * tree.cc (cxx_build_lang_qualified_type): New function. gcc/testsuite/ * c-c++-common/pr101312-1.c: New test. * c-c++-common/pr101312-2.c: New test.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 63065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63065&action=edit gcc16-pr101312.patch Untested fix.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I think this is about the differences between the generic build_qualified_type and the C/C++ FE c_build_qualified_type. build_type_attribute_qual_variant currently uses ttype = build_qualified_type (ttype, TYPE_UNQUALIFIED); if (lang_hooks.types.copy_lang_qualifiers && otype != TYPE_MAIN_VARIANT (otype)) ttype = (lang_hooks.types.copy_lang_qualifiers (ttype, TYPE_MAIN_VARIANT (otype))); and ttype = build_qualified_type (ntype, quals); if (lang_hooks.types.copy_lang_qualifiers && otype != TYPE_MAIN_VARIANT (otype)) ttype = lang_hooks.types.copy_lang_qualifiers (ttype, otype); in two spots and it is just the C++ FE which sets copy_lang_qualifiers langhook to non-NULL and it is solely these two spots that use the langhook. So, I wonder if we shouldn't nuke the copy_lang_qualifiers langhook and add a new one for build_qualified_type and use it either in these 2 or perhaps 3 (at the end of the same function) spots, defaulting to build_qualified_type and overridden by C and C++ FE to deal at least with ARRAY_TYPEs the normal C/C++ FE way and deal with the qualifiers for C++ too. The langhook has been added for PR70029.
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Andrew Pinski changed: What|Removed |Added CC||qingren2hxb at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 123154 has been marked as a duplicate of this bug. ***
[Bug c/101312] ICE with -g and may_alias and qualified (const or volatile) array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Andrew Pinski changed: What|Removed |Added CC||iamanonymous.cs at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 121193 has been marked as a duplicate of this bug. ***
