From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2iMpLVuIjWFxOwAAWB0awg (envelope-from ) for ; Thu, 11 Nov 2021 16:17:15 -0500 Received: by simark.ca (Postfix, from userid 112) id A7BF81F0BD; Thu, 11 Nov 2021 16:17:15 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 963C31ECEB for ; Thu, 11 Nov 2021 16:17:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DCA09385780A for ; Thu, 11 Nov 2021 21:17:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCA09385780A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1636665431; bh=NMuQfiQAQBtdtypi+XnKxJP613WMpTdv67Hru1m5q0s=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=IxP/FPmjAk7g4VAMj7kstC4L1xRiheVx3SfVY1hBHJSUKRQs4AzGXZsiaWJyLp8BP ylSOg1g8NYALqAJmqDoVqrWloNwMg5R5OMbplFWPUcPs+BkRSovRxSFb7g7odx5sR9 YaTbrciZNydaflnGT6kpGTX0uX664XL3T5aeYUWE= Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id C93653858408 for ; Thu, 11 Nov 2021 21:16:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C93653858408 Received: by smtp.gentoo.org (Postfix, from userid 559) id 65A1F342E16; Thu, 11 Nov 2021 21:16:51 +0000 (UTC) Date: Thu, 11 Nov 2021 16:16:54 -0500 To: Jeff Law Subject: Re: Minor fix for H8 simulator Message-ID: Mail-Followup-To: Jeff Law , gdb-patches@sourceware.org References: <36fb4284-5ddc-50c3-959c-b30e0cc96096@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FXe4EvCW+fAjLRu2" Content-Disposition: inline In-Reply-To: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" --FXe4EvCW+fAjLRu2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11 Nov 2021 11:06, Jeff Law via Gdb-patches wrote: > On 11/11/2021 10:55 AM, Mike Frysinger wrote: > > On 11 Nov 2021 09:50, Jeff Law via Gdb-patches wrote: > >> The upstream GCC tester has=C2=A0 showed spurious execution failures o= n the > >> H8 target for the H8/SX multilibs. I suspected memory corruption or an > >> uninitialized variable early as the same binary would sometimes work a= nd > >> sometimes it got the wrong result. Worse yet, the point where the test > >> determined it was getting the wrong result would change. > >> > >> Because it only happened on the H8/SX variant I was able to zero in on > >> the "mova" support and the "short form" of those instructions in parti= cular. > >> > >> As the code stands it checks if code->op3.type =3D=3D 0 to try and ide= ntify > >> cases where op3 wasn't filled in and thus we've got the short form of > >> the mova instruction. > >> > >> But for the short-form of those instructions we never set any of the > >> "op3" data structure. We get whatever was lying around -- it's usually > >> zero and thus things usually work, but if the stale data was nonzero, > >> then we'd fail to recognize the instruction as a short-form and fail to > >> set up the various fields appropriately. > >> > >> I initially initialized the op3.type field to zero, but didn't like th= at > >> because it was inconsistent with how other operands were initialized. > >> Bringing consistency meant using -1 as the initializer value and > >> adjusting the check for short form mova appropriately. > >> > >> I've had this in the upstream GCC tester for perhaps a year at this > >> point and haven't seen any of the intermittent failures again. > > > > can you update the unittests too ? > > IIRC it was dependent upon what instructions had recently executed as=20 > those impacted the state of code->op3.type -- my analysis is from over a= =20 > year ago and had been sitting in my todo box for a while.=C2=A0 Even just= =20 > reproducing was fairly painful. if reconstructing the failure is too hard now, and you think the existing unittests at least cover this insn in this mode at some level, then OK. feel free to merge. -mike --FXe4EvCW+fAjLRu2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmGNiEYACgkQQWM7n+g3 9YG8pg//Zl4WXTmzKAC99t4T1vQaxJmRQx1s9Y+BxkEAT/fUBReHwW4YpfZozGGC 7WtEvFBaPGqOjo+1gxOjspiTSMXK8y4ibADeyucSivyEvS8tCoYie/v0MBl57Iq4 jZKQmNG1UZskxzvayvQ8iuQtfemJGI60V670iJgUCo04FVeCXVhiHUOs4OikVZm+ AFpd/eKgFiCUqJzGKeLyscKys5EdRxMiWINONEi4MUDZvSWFwFEqkF29IEH8SNUx UAy+PWQqYjcEV5tWiPqs9ybPjvPRjWL7mZh6GeNEyAp9gsffHM4Mx8qY2T1QIOhp VALV05dK5+vnXSLNTxUgE9xTnVThTnWmBncFyFgTQ02FKUCJl7l/Rlw9spgFPPQg 64E8BXPVOutRAYtN12RTWwWThLkanbG0n9whiEmEh8IFGmSbtYnAzzZDQf9QRpXO IsnOD0tz4D0a/nF1CxbUKdTONfxLMLWM0NHb/nu5Kn328KMnQZKXEhLr9Uknf4l8 vUb0wyU+4KwLTPUNBUT92AbYUEcuSPwVO7Jm0sO4i0iSmIQq6R3Wt7epdpZTxeva AboDxSkk4S2wqVe8pFwXqMDfqK9qxdnyrq3/3N/gn3tpsYEKwPC3MDMyOFiGKwlI bziwgw5YmHMV4WPnn8ArDixn1KNBiTmvinxm+rW4W8lco+4rSWI= =K5KD -----END PGP SIGNATURE----- --FXe4EvCW+fAjLRu2--