https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126701
--- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > To answer myself, I can reproduce the ICE this testcase on 16 branch with a > x86_64-linux to aarch64-linux cross (just removed stdint.h include and > replaced uint64_t with unsigned long and uint8_t with unsigned char): > ./cc1 -quiet -nostdinc -O2 pr126701.c -march=armv9-a+sve -fchecking=1 > during RTL pass: expand > pr126701.c: In function ‘f30’: > pr126701.c:8:6: internal compiler error: in verify_partition_mem_exprs, at > cfgexpand.cc:2484 > 8 | void f30(unsigned long a0, _Bool a1, v16u64 a2) > | ^~~ > 0x1bcfc0d internal_error(char const*, ...) > ../../gcc/diagnostic-global-context.cc:787 > 0x4429d9 fancy_abort(char const*, int, char const*) > ../../gcc/diagnostics/context.cc:1813 > 0x5d28bb verify_partition_mem_exprs > ../../gcc/cfgexpand.cc:2484 > 0x5e0c14 execute > ../../gcc/cfgexpand.cc:7199 > and I can reproduce it also if I revert on the branch the r16-9426 and > r16-9425 commits (but keep the r16-9427). > So, the sharing problem was there already before (or the verification commit > has issues). Thus I'd say the right fix for 16.2 is to revert r16-9427. Ok, I'm fine with reverting that commit on the branch, but it's intended to catch real silent wrong-code that pair-fusion introduces if the checking code does not catch it first.
