[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Maciej W. Rozycki
<ma...@gcc.gnu.org>:

https://gcc.gnu.org/g:2c23fa691d23d9f3d57ac7feece6fbbb7236c563

commit r13-8089-g2c23fa691d23d9f3d57ac7feece6fbbb7236c563
Author: Maciej W. Rozycki <ma...@embecosm.com>
Date:   Wed Nov 22 01:27:02 2023 +0000

    PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT

    As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
    GCC for the `vax-netbsdelf' target fails to complete building, with an
    ICE:

    during RTL pass: final
    .../libbacktrace/elf.c: In function 'elf_zstd_decompress':
    .../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
     5006 | }
          | ^
    0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
            .../gcc/config/vax/vax.cc:514
    0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
            .../gcc/targhooks.cc:373
    0x106ddd0b output_address(machine_mode, rtx_def*)
            .../gcc/final.cc:3648
    0x106ddd0b output_asm_insn(char const*, rtx_def**)
            .../gcc/final.cc:3505
    0x106e2143 output_asm_insn(char const*, rtx_def**)
            .../gcc/final.cc:3421
    0x106e2143 final_scan_insn_1
            .../gcc/final.cc:2841
    0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
            .../gcc/final.cc:2887
    0x106e2bf7 final_1
            .../gcc/final.cc:1979
    0x106e3c67 rest_of_handle_final
            .../gcc/final.cc:4240
    0x106e3c67 execute
            .../gcc/final.cc:4318
    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.

    This is due to combine producing an invalid address RTX:

    (plus:SI (ashift:SI (const_int 1 [0x1])
            (reg:QI 3 %r3 [1232]))
        (reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

    where the expression is ((1 << R3) + R10), which does not match a valid
    machine addressing mode.  Consequently `print_operand_address' chokes.

    This can be reduced to the testcase included, where it triggers the same
    ICE in `p'.  Preincrements are required so that their results land in
    registers and consequently an indexed addressing mode is tried or
    otherwise doing operations piecemeal on stack-based function arguments
    as direct input operands turns out more profitable in terms of RTX costs
    and the ICE is avoided.

    The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
    address expressions"), where a shift of an immediate value by a register
    has been mistakenly allowed as an index expression as if the shift
    operation was commutative such as multiplication is.  So with ASHIFT the
    scaler in an index expression has to be the right-hand operand, and the
    backend has to enforce that, whereas with MULT the scaler can be either
    operand.

    Fix this by only accepting the index scaler as the RHS operand to
    ASHIFT.

            gcc/
            PR target/111815
            * config/vax/vax.cc (index_term_p): Only accept the index scaler
            as the RHS operand to ASHIFT.

            gcc/testsuite/
            PR target/111815
            * gcc.dg/torture/pr111815.c: New test.

    (cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)