[Bug c++/123970] ICE in lto_write_tree: tree code 'decltype_type' is not supported in LTO streams

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123970

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2026-02-04

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Reduced testcase, fails with -std=gnu++26 -flto.

#include <utility>

template<auto N>
void test()
{ 
  constexpr auto [id0, ...ids] = std::_IotaArray<N>;
}

int main()
{ 
  test<1>();
}


We're trying to stream

 <type_pack_expansion 0x7ffff617a690
    type <decltype_type 0x7ffff617a5e8 VOID
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality>
    VOID
    align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality>

and that's reachable from the 'test' functions IDS variable reachable
from its BLOCK tree:

 <var_decl 0x7ffff613ad10 ids
    type <type_pack_expansion 0x7ffff617a690
        type <decltype_type 0x7ffff617a5e8 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality>
        VOID
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality>
    ignored decl_1 decl_5 decl_8 VOID t.C:6:27
    align:8 warn_if_not_align:0 context <function_decl 0x7ffff6178300 test>
    value-expr <tree_vec 0x7ffff6719cd0 length:2
        elt:0 <var_decl 0x7ffff613abe0 D.12830 type <array_type 0x7ffff617a888>
            constant decl_1 decl_5 decl_8 SI t.C:6:18
            size <integer_cst 0x7ffff681b4f8 constant 32>
            unit-size <integer_cst 0x7ffff681b510 constant 4>
            align:32 warn_if_not_align:0 context <function_decl 0x7ffff6178300
test> chain <var_decl 0x7ffff613ac78 id0>>
        elt:1 <integer_cst 0x7ffff681b3c0 constant 1>>>

so it's arguably a frontend free-lang-data issue again.