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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<ja...@gcc.gnu.org>:

https://gcc.gnu.org/g:3abc678a266a5ae130b45591f09ba51618926001

commit r13-9607-g3abc678a266a5ae130b45591f09ba51618926001
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Mon Apr 14 19:34:22 2025 +0200

    expmed: Always use QImode for init_expmed set_zero_cost [PR119785]

    This is a regression on some targets introduced I believe by r6-2055
    which added mode argument to set_src_cost.

    The problem here is that in the first iteration, mode is always QImode
    and we get as -Os zero cost set_src_cost (const0_rtx, QImode, false).
    But then we use the mode variable for iterating over int, partial int
    and vector int modes, so for the second iteration we call set_src_cost
    with mode which is at that time (machine_mode) (MAX_MODE_VECTOR_INT + 1).

    In the x86 case that happens to be V2HFmode and we don't crash (and
    compute the same 0 cost as we would for QImode).
    But e.g. in the SPARC case (machine_mode) (MAX_MODE_VECTOR_INT + 1) is
    MAX_MACHINE_MODE and that does all kinds of weird things especially
    when doing ubsan bootstrap.

    Fixed by always using QImode.

    2025-04-14  Jakub Jelinek  <ja...@redhat.com>

            PR rtl-optimization/119785
            * expmed.cc (init_expmed): Always pass QImode rather than mode to
            set_src_cost passed to set_zero_cost.

    (cherry picked from commit f96a54350afcf7f3c90d0ecb51d7683d826acc00)

Reply via email to