From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 78B70385802D; Fri, 23 Oct 2020 08:11:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78B70385802D From: "crazylht at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196 Date: Fri, 23 Oct 2020 08:11:37 +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: X-Bugzilla-Severity: normal X-Bugzilla-Who: crazylht at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 08:11:37 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97532 --- Comment #8 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #7) > memory_operand calls general_operand which for MEM does: > /* Use the mem's mode, since it will be reloaded thus. LRA can > generate move insn with invalid addresses which is made valid > and efficiently calculated by LRA through further numerous > transformations. */ > if (lra_in_progress > || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE > (op))) > return 1; > So, during LRA it accepts anything, and at the end of LRA it ICEs because= it > isn't recognized. > So, I think LRA needs to know somewhere what is the address operand of the > MEM even inside of the bcst_mem_operand and know that it should fix it up. Yes, and i saw at least two places needed to be adjusted. First in process_address_1 (int nop, bool check_only_p, --- 3430 /* Do not attempt to decompose arbitrary addresses generated by comb= ine 3431 for asm operands with loose constraints, e.g 'X'. */ 3432 else if (MEM_P (op) ---------------------------------------> Here!!! 3433 && !(INSN_CODE (curr_insn) < 0 3434 && get_constraint_type (cn) =3D=3D CT_FIXED_FORM 3435 && constraint_satisfied_p (op, cn))) 3436 decompose_mem_address (&ad, op); 3437 else if (GET_CODE (op) =3D=3D SUBREG 3438 && MEM_P (SUBREG_REG (op))) 3439 decompose_mem_address (&ad, SUBREG_REG (op)); 3440 else 3441 return false; --- Then in valid_address_p which would be called in process_address_1 --- 398 /* Return true if the eliminated form of AD is a legitimate target address. 399 If OP is a MEM, AD is the address within OP, otherwise OP should be 400 ignored. CONSTRAINT is one constraint that the operand may need 401 to meet. */ 402 static bool 403 valid_address_p (rtx op, struct address_info *ad, 404 enum constraint_num constraint) 405 { 406 address_eliminator eliminator (ad); 407=20 408 /* Allow a memory OP if it matches CONSTRAINT, even if CONSTRAINT is more 409 forgiving than "m". */ 410 if (MEM_P (op) -----------------------------------------------> Here. 411 && (insn_extra_memory_constraint (constraint) 412 || insn_extra_special_memory_constraint (constraint)) 413 && constraint_satisfied_p (op, constraint)) 414 return true; 415=20 416 return valid_address_p (ad->mode, *ad->outer, ad->as); 417 } ---=