> The (proposed) solution is to export store_constructor (and it's helper > function int_expr_size) from expr.cc, by removing their static qualifier > and prototyping both functions in expr.h, so they can be called directly > from load_register_parameters in calls.cc. This cures both ICEs, but > almost as important produces much better code generation than GCC 12. > > For PR 105853, GCC 12 generates: > > compose_nd_na_ipv6_src: > movzx eax, WORD PTR eth_addr_zero[rip+2] > movzx edx, WORD PTR eth_addr_zero[rip] > movzx edi, WORD PTR eth_addr_zero[rip+4] > sal rax, 16 > or rax, rdx > sal rdi, 32 > or rdi, rax > xor eax, eax > jmp packet_set_nd > eth_addr_zero: .zero 6 > > where now (with this fix) GCC 13 generates: > compose_nd_na_ipv6_src: > xorl %edi, %edi > xorl %eax, %eax > jmp packet_set_nd > > Likewise, for PR 105856 on ARM, we'd previously generate: > g_329_3: > movw r3, #:lower16:.LANCHOR0 > movt r3, #:upper16:.LANCHOR0 > ldr r0, [r3] > b func_19 > > but with this optimization we now generate: > g_329_3: > mov r0, #6 > b func_19
Nice work! Fiddling with RTL expansion like this is never easy... > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check with no new failures. I've also confirmed that on a > cross-compiler to arm-linux-gnueabihf --with-arch=armv6 this fixes the > target specific ICE in PR105856. The make check is currently running > with --target_board=unix{-m32}, OK for mainline if that also passes? Yes, it looks quite uncontroversial if you ask me and will unblock people. -- Eric Botcazou