Can you please show back-trace (export UBSAN_OPTIONS="print_stacktrace=1")?

(In reply to Martin Liška from comment #1)
> Can you please show back-trace (export UBSAN_OPTIONS="print_stacktrace=1")?

I didn't know ubsan did that, thanks! Here is the backtrace:

/home/alecop01/toolchain/src/gcc/gcc/poly-int.h:1095:5: runtime error: signed integer overflow: -8846744073709551616 * 8 cannot be represented in type 'long int'
    #0 0x26a75c0 in poly_int<2u, poly_result<long, if_nonpoly<int, int, poly_int_traits<int>::is_poly>::type, poly_coeff_pair_traits<long, if_nonpoly<int, int, poly_int_traits<int>::is_poly>::type>::result_kind>::type> operator*<2u, long, int>(poly_int_pod<2u, long> const&, int const&) /home/alecop01/toolchain/src/gcc/gcc/poly-int.h:1095
    #1 0x26a75c0 in fully_constant_vn_reference_p(vn_reference_s*) /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:1540
    #2 0x26d45e0 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool, tree_node**, tree_node*) /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:3596
    #3 0x26e5378 in visit_reference_op_load /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:5061
    #4 0x26e5378 in visit_stmt /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:5501
    #5 0x26e7d94 in process_bb /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:7201
    #6 0x26edfa4 in do_rpo_vn /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:7800
    #7 0x26f5c54 in execute /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-sccvn.c:7954
    #8 0x1b5ec1c in execute_one_pass(opt_pass*) /home/alecop01/toolchain/src/gcc/gcc/passes.c:2567
    #9 0x1b623b8 in execute_pass_list_1 /home/alecop01/toolchain/src/gcc/gcc/passes.c:2656
    #10 0x1b623f0 in execute_pass_list_1 /home/alecop01/toolchain/src/gcc/gcc/passes.c:2657
    #11 0x1b624d4 in execute_pass_list(function*, opt_pass*) /home/alecop01/toolchain/src/gcc/gcc/passes.c:2667
    #12 0xc7b2a4 in cgraph_node::expand() /home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:1830
    #13 0xc7ff24 in expand_all_functions /home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:1994
    #14 0xc7ff24 in symbol_table::compile() /home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:2358
    #15 0xc8b81c in symbol_table::compile() /home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:2271
    #16 0xc8b81c in symbol_table::finalize_compilation_unit() /home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:2539
    #17 0x1f97478 in compile_file /home/alecop01/toolchain/src/gcc/gcc/toplev.c:482
    #18 0x68d9b0 in do_compile /home/alecop01/toolchain/src/gcc/gcc/toplev.c:2201
    #19 0x68d9b0 in toplev::main(int, char**) /home/alecop01/toolchain/src/gcc/gcc/toplev.c:2340
    #20 0x6910d0 in main /home/alecop01/toolchain/src/gcc/gcc/main.c:39
    #21 0xffffa682f6dc in __libc_start_main (/lib/aarch64-linux-gnu/libc.so.6+0x206dc)
    #22 0x691b2c  (/data/alecop01/builds/bstrap-ubsan/gcc/cc1+0x691b2c)

I can confirm that on x86_64, it's likely dup of PR90242.

It's similar, yes.

              wi::overflow_type ovf = wi::OVF_NONE;
              off = wi::mul (off, (HOST_WIDE_INT)BITS_PER_UNIT, SIGNED, &ovf);
              if (ovf == wi::OVF_NONE)

doesn't like me though.

In file included from /home/rguenther/src/gcc3/gcc/coretypes.h:469:0,
                 from /home/rguenther/src/gcc3/gcc/tree-ssa-sccvn.c:23:
/home/rguenther/src/gcc3/gcc/poly-int.h: In instantiation of 'poly_int<N, C>& poly_int<N, T>::operator=(const poly_int_pod<N, Ca>&) [with Ca = generic_wide_int<fixed_wide_int_storage<192> >; unsigned int N = 1; C = long int]':
/home/rguenther/src/gcc3/gcc/tree-ssa-sccvn.c:1544:70:   required from here
/home/rguenther/src/gcc3/gcc/poly-int.h:693:21: error: cannot convert 'const generic_wide_int<fixed_wide_int_storage<192> >' to 'long int' in assignment
     this->coeffs[i] = a.coeffs[i];
     ~~~~~~~~~~~~~~~~^~~~~~~~~~~

neither attempts to go via poly_offset_int and a "fits uhwi" (fold_ctor_referece takes an unsigned offset).