From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id b9+bAMx+sWk1xiMAWB0awg (envelope-from ) for ; Wed, 11 Mar 2026 10:40:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1773240011; bh=6y3xq3cQOjY+2jMYVBelkQXVAfDixWaGsX9Sk0an+0s=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=V8sSOBquE0jMVXmGLyiFTeEtewXuMWAIq+rNh6TbalBg2H76kUOMMvIY+3ae5LxK3 8hyXmf3CCAnw35pHklYBuLiq4agfrbpmL1zj4EUQkeMeXpVHPQuVvfXY3Bfd2W6zBV A8ckBGn7CzVQZoc9DvXC5V+Md3LX14Spc3yzn/fI= Received: by simark.ca (Postfix, from userid 112) id DC8BC1E0DD; Wed, 11 Mar 2026 10:40:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Naw8EtJF; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E1DB51E08D for ; Wed, 11 Mar 2026 10:40:10 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A48524BB58AA for ; Wed, 11 Mar 2026 14:40:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A48524BB58AA Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Naw8EtJF Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BCF784BB58AB for ; Wed, 11 Mar 2026 14:39:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCF784BB58AB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BCF784BB58AB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773239984; cv=none; b=CwTBiUYMXbklbU5IASiHa8vnIcg0x5HPzYfffLSLRULmiWsm0iiFEbpfbp/5WRnXfk1OpWLc4nQkd/eg5g6zAceMqY41ZD852jXfZMY5nwkmdJ+4/yc+J9uXemS8ekpGK6v2/xocERrdfcDP876nxCONgENxhLqGgtCepCeCBI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773239984; c=relaxed/simple; bh=6y3xq3cQOjY+2jMYVBelkQXVAfDixWaGsX9Sk0an+0s=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=TkUip9KAmh4ZBz5JBmT33u4IO+qTaKht6nG+yYTnqKsUBWPNnUP3F2DMGNlkv78CkpCbzXDVmX7JQTa6hjhKusRzetqsgFllasEr3DJMRiYreQNNBVMDNWkm/Cnn8P12TyftSRYOOBHtToilHs9jOEiXc6COz0iJ5mYYq60TESA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCF784BB58AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1773239984; bh=6y3xq3cQOjY+2jMYVBelkQXVAfDixWaGsX9Sk0an+0s=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Naw8EtJFR+WM1SqJtcb1phFCb/y02nKUDU/+M5FY4AzW1vsjpz1bj00DO3wW9qKrl nyIuVtYRfpIrPrVLx6onNMvd5B5NLmrRh/ne99e7fKMRCs+mZEPY1LaWPLkc/7IGvG iwKQ9K63amNq+5fBzLCHQSWcAb5Drp7NKwqxOqEc= Received: by simark.ca (Postfix) id 6A1141E08D; Wed, 11 Mar 2026 10:39:43 -0400 (EDT) Message-ID: <9855a27b-78f6-4d4a-b0f6-04fefcaf7a49@simark.ca> Date: Wed, 11 Mar 2026 10:39:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator To: Oleg Endo , gdb-patches@sourceware.org References: <016918b6653a40835d2272c3c37d05b0d7e470b6.camel@gmail.com> <6eb50919-75d8-4725-9afa-e241e4cabab6@simark.ca> Content-Language: fr From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 3/11/26 2:20 AM, Oleg Endo wrote: > On Wed, 2026-03-11 at 00:27 -0400, Simon Marchi wrote: >> >> On 2026-03-10 23:02, Oleg Endo wrote: >>> Hi, >>> >>> On SH variants with double-precision FPU the insns fli0 and flid1 require >>> that FPSCR.PR must be set to 0, i.e. single-precision mode. The attached >>> patch fixes that. >>> >>> OK to apply? >>> >>> Best regards, >>> Oleg Endo >> >> I looked for an ISA manual [1] and checked it for fun. For the FLID0, >> it says: >> >> When FPSCR.PR = 0, this instruction loads floating-point 0.0 (0x00000000) into FRn. >> >> Curiously, it does not say what happens if `FPSCR.PR = 1`. However, >> the description for FPSCR.PR says: >> >> PR: Precision mode >> PR = 0: Floating-point instructions are executed as single-precision operations. >> PR = 1: Floating-point instructions are executed as double-precision operations (the result of >> instructions for which double-precision is not supported is undefined). >> >> I guess that FLID0 and FLID1 fall into that "is undefined" category? >> Do you know what the real hardware does in this case? > > I have not checked what exactly happens on real hardware. I have checked a > few ISA manuals (Renesas, ST). The instruction descriptions doesn't say > that FLDI0 / FLID1 raises an exception (when in the wrong mode). So I guess > it will produce garbage quietly. Maybe some silicon implementations have > actually an undocumented but well defined behavior. Ok, well since we're in "undefined behavior" territory we could argue that the current sim behavior is fine. But I think the patch is still good, traping is a more useful behavior to catch something you don't want to happen. > > QEMU traps in this case. We found this while chasing an GCC bug. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182 > > I find using sh-sim for compiler testing quite useful. Hence this patch. Good to know, thanks. We often wonder "does anybody still use some old architecture or feature X in gdb". >> The patch LGTM, but I am not a maintainer of the sim, so: >> >> Reviewed-By: Simon Marchi >> >> One note, please put the relevant information (the body of your email) >> into the commit log itself). > > Yeah, sure I can expand the comment of the commit. Updated patch/commit > attached. I would give it a week for Andrew or Mike to review and approve, but otherwise I would feel comfortable merging it. Simon