public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/97971] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:3110
Date: Tue, 20 Apr 2021 23:31:56 +0000	[thread overview]
Message-ID: <bug-97971-4-i7pS3fErq6@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97971-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r9-9414-g2f9a241a308c32108b922bd768b7576c5c34e440
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 3 09:07:36 2021 +0100

    lra-constraints: Fix error-recovery for bad inline-asms [PR97971]

    The following testcase has ice-on-invalid, it can't be reloaded, but we
    shouldn't ICE the compiler because the user typed non-sense.

    In current_insn_transform we have:
      if (process_alt_operands (reused_alternative_num))
        alt_p = true;

      if (check_only_p)
        return ! alt_p || best_losers != 0;

      /* If insn is commutative (it's safe to exchange a certain pair of
         operands) then we need to try each alternative twice, the second
         time matching those two operands as if we had exchanged them.  To
         do this, really exchange them in operands.

         If we have just tried the alternatives the second time, return
         operands to normal and drop through.  */

      if (reused_alternative_num < 0 && commutative >= 0)
        {
          curr_swapped = !curr_swapped;
          if (curr_swapped)
            {
              swap_operands (commutative);
              goto try_swapped;
            }
          else
            swap_operands (commutative);
        }

      if (! alt_p && ! sec_mem_p)
        {
          /* No alternative works with reloads??  */
          if (INSN_CODE (curr_insn) >= 0)
            fatal_insn ("unable to generate reloads for:", curr_insn);
          error_for_asm (curr_insn,
                         "inconsistent operand constraints in an %<asm%>");
          lra_asm_error_p = true;
    ...
    and so handle inline asms there differently (and delete/nullify them after
    this) - fatal_insn is only called for non-inline asm.
    But in process_alt_operands we do:
                    /* Both the earlyclobber operand and conflicting operand
                       cannot both be user defined hard registers.  */
                    if (HARD_REGISTER_P (operand_reg[i])
                        && REG_USERVAR_P (operand_reg[i])
                        && operand_reg[j] != NULL_RTX
                        && HARD_REGISTER_P (operand_reg[j])
                        && REG_USERVAR_P (operand_reg[j]))
                      fatal_insn ("unable to generate reloads for "
                                  "impossible constraints:", curr_insn);
    and thus ICE even for inline-asms.

    I think it is inappropriate to delete/nullify the insn in
    process_alt_operands, as it could be done e.g. in the check_only_p mode,
    so this patch just returns false in that case, which results in the
    caller have alt_p false, and as inline asm isn't simple move, sec_mem_p
    will be also false (and it isn't commutative either), so for check_only_p
    it will suggests to the callers it isn't ok and otherwise will emit
    error and delete/nullify the inline asm insn.

    2021-02-03  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/97971
            * lra-constraints.c (process_alt_operands): For inline asm, don't
call
            fatal_insn, but instead return false.

            * gcc.target/i386/pr97971.c: New test.

    (cherry picked from commit 4dd7141653b57f638fc32291245d57d4dcfa3813)

  parent reply	other threads:[~2021-04-20 23:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 18:26 [Bug c/97971] New: [9/10/11 " gscfq@t-online.de
2020-11-24 19:19 ` [Bug c/97971] " jakub at gcc dot gnu.org
2020-11-25  8:18 ` rguenth at gcc dot gnu.org
2021-01-14  9:44 ` rguenth at gcc dot gnu.org
2021-02-01 13:29 ` [Bug middle-end/97971] " jakub at gcc dot gnu.org
2021-02-03  8:10 ` cvs-commit at gcc dot gnu.org
2021-02-03  8:12 ` [Bug middle-end/97971] [9/10 " jakub at gcc dot gnu.org
2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org
2021-03-20  8:06 ` [Bug middle-end/97971] [9 " jakub at gcc dot gnu.org
2021-04-20 23:31 ` cvs-commit at gcc dot gnu.org [this message]
2021-04-22 13:34 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-97971-4-i7pS3fErq6@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).