Hi,
I've found recently that rs6000 and powerpcspe backends can easily trip over
various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
print_operand() when provided with some invalid assembly (i.e. assembly written
for other architectures). For example, when feeding
gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c to the
powerpc-targeted compiler:
% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -c
gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c
during RTL pass: final
gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c: In function 'foo':
gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c:10:1: internal
compiler error: in print_operand, at config/rs6000/rs6000.c:20992
10 | }
| ^
0x6da7e3 print_operand(_IO_FILE*, rtx_def*, int)
<…>/gcc-9-20181118/gcc/config/rs6000/rs6000.c:20992
0x9eb84f output_operand(rtx_def*, int)
<…>/gcc-9-20181118/gcc/final.c:4042
0x9ec4d6 output_asm_insn(char const*, rtx_def**)
<…>/gcc-9-20181118/gcc/final.c:3935
0x9ee6a6 final_scan_insn_1
<…>/gcc-9-20181118/gcc/final.c:2712
0x9ee998 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
<…>/gcc-9-20181118/gcc/final.c:3149
0x9eecae final_1
<…>/gcc-9-20181118/gcc/final.c:2019
0x9ef838 rest_of_handle_final
<…>/gcc-9-20181118/gcc/final.c:4649
0x9ef838 execute
<…>/gcc-9-20181118/gcc/final.c:4723
I have a hunch that this kind of invalid input should have been rejected way
earlier, before getting to the printing out the resulting assembly, and that
i386 backend actually does exactly that. Still, I'm not convinced that the
current behavior is really unintended. Is it worthwhile at all to report ICEs of
this kind?
Thanks.
