From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ln01.mxout.alfaservers.com (ln01.mxout.alfaservers.com [85.17.185.57]) by sourceware.org (Postfix) with ESMTPS id A20253857C4F for ; Mon, 19 Oct 2020 15:54:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A20253857C4F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=blueice.be Authentication-Results: sourceware.org; spf=none smtp.mailfrom=henri.cloetens@blueice.be Received: from [193.121.150.145] (port=59706 helo=[192.168.178.60]) by ln01.alfaservers.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1kUXUm-0000Ee-CH for gcc-help@gcc.gnu.org; Mon, 19 Oct 2020 17:54:48 +0200 Subject: Re: Issue during combine. To: gcc-help@gcc.gnu.org References: From: Henri Cloetens Message-ID: <2ade57f1-ff38-553c-0e06-1cbb445f5d4e@blueice.be> Date: Mon, 19 Oct 2020 17:55:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-MW X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ln01.alfaservers.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blueice.be X-Get-Message-Sender-Via: ln01.alfaservers.com: authenticated_id: henri.cloetens@blueice.be X-Authenticated-Sender: ln01.alfaservers.com: henri.cloetens@blueice.be X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:54:50 -0000 Hello all, This seems to be a bug in the non-port code of the compiler. It crashes in /rtx simplify_subreg(machine_mode outer_mode, rtx op, machine_mode inner_mode, poly_uint64 byte)/ The crash is, because this function is called with inner_mode = Voidmode. (And seems illegal.) It seems to me this "illegal" mode is the result of the /combine/ step, trying to "improve" by doing combinations of instructions "at random". Here, it tries a "combination" that does not make sense, but it causes a crash in the abovementioned routine. When I change the code, so that this routine returns 0 (=fail the operation), it passes the '263 step without errors. The meaningless combination is refused elsewhere. It is not done. Best Regards, Henri. On 10/19/2020 02:53 PM, Henri Cloetens wrote: > Hello all, > > I am building a gcc 9.2.0 custom compiler, and I am running in an > issue during step 263, combine. > > Before combine: > > /(insn 2354 2352 1743 175 (set (reg/v:SI 197 [ dig ])// > //        (if_then_else (eq (subreg:QI (reg:SI 632) 1)// > //                (const_int 1 [0x1]))// > //            (reg:SI 708)// > //            (reg/v:SI 197 [ dig ]))) > "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":771:6 35 > {select_internal3}// > //     (expr_list:REG_DEAD (reg:SI 708)// > //        (expr_list:REG_DEAD (reg:SI 632)// > //            (nil))))// > //(insn 1743 2354 124 175 (set (mem:QI (reg:SI 316 [ ivtmp.118 ]) [0 > *s_304+0 S1 A8])// > //        (subreg:QI (reg/v:SI 197 [ dig ]) 0)) > "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":772:13 6 > {movqi_internal}// > //     (expr_list:REG_DEAD (reg:SI 316 [ ivtmp.118 ])// > //        (expr_list:REG_DEAD (reg/v:SI 197 [ dig ])// > //            (nil))))/ > > This is during the combine-step transformed into: > > /(insn 1743 2354 124 175 (set (mem:QI (reg:SI 316 [ ivtmp.118 ]) [0 > *s_304+0 S1 A8])// > //        (subreg:QI (if_then_else (eq (subreg:QI (reg:SI 632) 1)// > //                    (const_int 1 [0x1]))// > //                (reg:SI 708)// > //                (reg/v:SI 197 [ dig ])) 0)) > "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":772:13 6 > {movqi_internal}// > //     (expr_list:REG_DEAD (reg:SI 316 [ ivtmp.118 ])// > //        (expr_list:REG_DEAD (reg/v:SI 197 [ dig ])// > //            (nil))))/ > > This, of course, is not correct any more. Now, how should I prevent > this ?, the pattern is defined in the .md-file as: > > /(define_insn "movqi_internal" // > //[(set (match_operand:QI 0 "movqi_operand_0" > "=r,r,r,r,r,r,u,u,W,t,r,c,*c*l,*h,*h,y")// > //(match_operand:QI 1 "movqi_operand_1" "O,k,i,r,W,t,W,t,r,r,*h,u, > r,   r, 0,y"))]/ > > /.../ > and /movqi_operand_1/ is defined as: > > /(define_predicate "movqi_operand_1"// > //  (ior (match_operand 0 "gpc_reg_operand")// > //       (ior (match_operand 0 > "quarterword_offset21_memref_operand_or_indirect")// > //            (match_operand 0 "immediate_operand"))))/ > > > and /gpc_reg_operand/ as: > > /(define_predicate "gpc_reg_operand"// > //   (and (match_operand 0 "register_operand")// > //        (match_test "(GET_CODE (op) != REG && GET_CODE(op) != SUBREG// > //                      || (REGNO (op) >= ARG_POINTER_REGNUM// > //                          && !CA_REGNO_P (REGNO (op)))// > //                      || REGNO (op) == SFP_REGNO// > //                      || REGNO (op) == ARG_POINTER_REGNUM// > //                      || REGNO (op) <= MAX_REGFILE_REGNO)")))/ > > Any of you any idea why the combine succeeds ?. I mean, it should fail > !. After combine, it does not match /movqi_internal/ pattern > any more, but the compiler seems to think otherwise !. > > Best Regards, > > Henri. > > >