From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 9F8623894C18; Thu, 11 Mar 2021 23:38:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F8623894C18
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/99422] [11 Regression] ICE in extract_constrain_insn
 building glibc pthread_create
Date: Thu, 11 Mar 2021 23:38:09 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99422-4-xzSJRx2V9m@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99422-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99422-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 23:38:09 -0000

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

--- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Before the patches function process_address_1 used CONSTRAINT__UNKNOWN
> (taken from '=3D' of constraint "=3DT,..." and this is wrong) to check va=
lidity
> address.  It was invalid and LRA added reloads for the address.

Is that because T is a special_memory_constraint or did it happen with a
regular memory_constraint as well?

> After the patches, the function uses CONTSTRAINT_T (taken from 'T').  For
> constraint T sparc code says that the memory address is ok and LRA keeps =
the
> address and does not generate reloads.

So LRA does not check that the memory is valid for special_memory_constrain=
t or
memory_constraint, and the constraint must do it on its own?  Then it's
probably inherited from reload and I guess that

  if (! can_create_pseudo_p ()
      && !strict_memory_address_p (Pmode, XEXP (op, 0)))
    return 0;

was supposed to do it, in which case David and I missed it when we converted
the port to LRA.  This would point to:

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index f1504172022..d8860f908e9 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -9227,7 +9227,7 @@ memory_ok_for_ldd (rtx op)
   if (TARGET_ARCH32 && !mem_min_alignment (op, 8))
     return 0;

-  if (! can_create_pseudo_p ()
+  if ((lra_in_progress || reload_in_progress)
       && !strict_memory_address_p (Pmode, XEXP (op, 0)))
     return 0;

Thanks for the investigation, I'll take over from there.=