Maybe a similar issue to PR 81050, i.e. Latin1 isn't valid as a wide charset. In which case, we should give an error instead of ICE if possible.


Reduced to remove library headers and C++20 features:

template<typename, typename> constexpr bool is_same_v = false;
template<typename T> constexpr bool is_same_v<T,T> = true;

template<typename CharT>
auto
units_suffix() noexcept
{
  if constexpr (is_same_v<CharT, wchar_t>)
    return L"ms";
  else
    return "ms";
}

int main()
{
  units_suffix<wchar_t>();
}


during RTL pass: expand
ice.cc: In function ‘auto units_suffix() [with CharT = wchar_t]’:
ice.cc:9:12: internal compiler error: in get_constant_size, at varasm.cc:3418
    9 |     return L"ms";
      |            ^~~~~
0x8a6410 get_constant_size
        /home/jwakely/src/gcc/gcc/gcc/varasm.cc:3418
0x1519a88 assemble_constant_contents
        /home/jwakely/src/gcc/gcc/gcc/varasm.cc:3615
0x151af15 output_constant_def_contents
        /home/jwakely/src/gcc/gcc/gcc/varasm.cc:3666
0x151b264 maybe_output_constant_def_contents
        /home/jwakely/src/gcc/gcc/gcc/varasm.cc:3602
0x151b264 output_constant_def(tree_node*, int)
        /home/jwakely/src/gcc/gcc/gcc/varasm.cc:3568
0xe23b2e expand_expr_constant
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:8592
0xe23b2e expand_expr_addr_expr_1
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:8619
0xe24169 expand_expr_addr_expr
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:8812
0xe19464 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:12096
0xe26825 store_expr(tree_node*, rtx_def*, int, bool, bool)
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:6330
0xe28090 expand_assignment(tree_node*, tree_node*, bool)
        /home/jwakely/src/gcc/gcc/gcc/expr.cc:6051
0xcf589c expand_gimple_stmt_1
        /home/jwakely/src/gcc/gcc/gcc/cfgexpand.cc:3946
0xcf589c expand_gimple_stmt
        /home/jwakely/src/gcc/gcc/gcc/cfgexpand.cc:4044
0xcfc0ce expand_gimple_basic_block
        /home/jwakely/src/gcc/gcc/gcc/cfgexpand.cc:6096
0xcfdbe7 execute
        /home/jwakely/src/gcc/gcc/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.




And this does ICE "gcc version 12.0.1 20220316 (experimental) (GCC)" so it probably is due to checking.

Started with r9-2891-g5ec9f8cff333bbe9.

3416      size = int_size_in_bytes (TREE_TYPE (exp));
3417      gcc_checking_assert (size >= 0);
3418      gcc_checking_assert (TREE_CODE (exp) != STRING_CST
3419                           || size >= TREE_STRING_LENGTH (exp));
(gdb) p size
$1 = 4
(gdb) p exp->string.length
$3 = 6
(gdb) p debug_tree (exp)
 <string_cst 0x7ffff6408b80
    type <array_type 0x7ffff6428150
        type <integer_type 0x7ffff6428000 wchar_t readonly type_6 SI
            size <integer_cst 0x7ffff628b210 constant 32>
            unit-size <integer_cst 0x7ffff628b228 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6428000 precision:32 min <integer_cst 0x7ffff628b5d0 -2147483648> max <integer_cst 0x7ffff628b5e8 2147483647>
            pointer_to_this <pointer_type 0x7ffff6428888>>
        type_6 SI size <integer_cst 0x7ffff628b210 32> unit-size <integer_cst 0x7ffff628b228 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6428150
        domain <integer_type 0x7ffff6294d20 type <integer_type 0x7ffff6289000 sizetype>
            type_6 DI
            size <integer_cst 0x7ffff6266fc0 constant 64>
            unit-size <integer_cst 0x7ffff6266fd8 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6294d20 precision:64 min <integer_cst 0x7ffff628b000 0> max <integer_cst 0x7ffff628b000 0>>
        pointer_to_this <pointer_type 0x7ffff6428a80>>
    readonly constant asm_written static "ms\000\000\000\000">
(gdb) p debug_generic_expr (0x7ffff6428150)
const wchar_t[1]

Bernd - I see it as us having an excess 2-byte nul terminator?

The assumption is that for wide charsets each char is either a wchar_t or multiple wchar_t, so I think such option is invalid; though not really sure how we could find that out and diagnose, iconv doesn't announce such details, for iconv everything is a series of bytes...

GCC 10 branch is being closed.