[Bug c++/123578] -fdump-tree-all ICEs
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Sun Mar 8 05:18:27 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123578
--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:8814fafd232f30f1b79f54cd0af39d1aae20b30f
commit r15-10888-g8814fafd232f30f1b79f54cd0af39d1aae20b30f
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 27 10:19:39 2026 +0100
c++: Fix ICE in cxx_printable_name_internal [PR123578]
On the following testcase, we end up with cxx_printable_name_internal
recursion, in particular
+../../gcc/cp/pt.cc:20736
+../../gcc/cp/error.cc:625
+template_args=<tree_vec 0x7fffe94b59b0>, flags=4) at
../../gcc/cp/error.cc:1876
The ICE is due to double free, that function is doing caching of up to 4
printed names, but if such a recursion happens, the inner call can change
ring_counter etc. and the caller will then store the result in a different
ring element from what was freed and so the freed one can be left
unmodified.
The patch fixes it by moving the lang_decl_name call earlier, after the:
/* See if this print name is lying around. */
for (i = 0; i < PRINT_RING_SIZE; i++)
if (uid_ring[i] == DECL_UID (decl) && translate == trans_ring[i])
/* yes, so return it. */
return print_ring[i];
loop and repeating the loop again just for the theoretical case
that some recursion would add the same entry.
The ring_counter adjustment and decision which cache entry to reuse
for the cache is then done without the possibility of ring_counter
or the cache being changed in the middle.
2026-01-27 Jakub Jelinek <jakub@redhat.com>
PR c++/123578
* tree.cc (cxx_printable_name_internal): Call lang_decl_name before
finding the slot to cache it in and repeat search in the cache
after the call.
* g++.dg/cpp2a/pr123578.C: New test.
(cherry picked from commit d341b0d57fc61e58598f072a5c2be1f8a5873ff3)
More information about the Gcc-bugs
mailing list