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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <[email protected]>:

https://gcc.gnu.org/g:896c822afed0aad4c0ca761777cdc5f0085bbce0

commit r17-890-g896c822afed0aad4c0ca761777cdc5f0085bbce0
Author: Jakub Jelinek <[email protected]>
Date:   Thu May 28 10:28:12 2026 +0200

    i386: Fix up *add<mode>_1<nf_name> [PR125469]

    The following testcase ICEs, because combine matches
    (set (reg:DI 108) (plus:DI (reg:DI 104 [ s ]) (subreg:DI (reg:TI 103 [ _2
]) 8)))
    Now, because ix86_validate_address_register has:
    12038         /* Don't allow SUBREGs that span more than a word.  It can
    12039            lead to spill failures when the register is one word out
    12040            of a two word structure.  */
    12041         if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
    12042           return NULL_RTX;
    this isn't recognized as *leadi, but is recognized as *adddi_1_nf pattern
    instead.  Now, later on the RA turns it into:
    (set (reg:DI 2 cx [108]) (plus:DI (reg:DI 0 ax [orig:104 s ] [104]) (reg:DI
5 di [ _2+8 ])))
    which would be valid *leadi, but given that INSN_CODE is already set to the
    *adddi_1_nf and that also satisfies it, nothing re-recognizes it as *leadi.
    But in that case without TARGET_APX_NDD the pattern has return "#";
    That is a bug, because there is no splitter to split that
    (set (reg:DI 2 cx [108]) (plus:DI (reg:DI 0 ax [orig:104 s ] [104]) (reg:DI
5 di [ _2+8 ])))
    into itself so that it is re-recognized as *leadi, so it just ICEs.
    I think having a splitter to split to the same thing would be just weird,
so
    this just outputs lea insn directly.

    2026-05-28  Jakub Jelinek  <[email protected]>

            PR target/125469
            * config/i386/i386.md (*add<mode>_1<nf_name>): Don't return "#" for
            the lea non-TARGET_APX_NDD case, instead emit a lea directly.

            * gcc.target/i386/apx-nf-pr125469.c: New test.

    Reviewed-by: Uros Bizjak <[email protected]>

Reply via email to