From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NmoU2-00057h-Up
	for qemu-devel@nongnu.org; Wed, 03 Mar 2010 08:19:27 -0500
Received: from [199.232.76.173] (port=59768 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NmoU2-00057U-Jq
	for qemu-devel@nongnu.org; Wed, 03 Mar 2010 08:19:26 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <rth7680@gmail.com>) id 1NmoTz-0007Nb-04
	for qemu-devel@nongnu.org; Wed, 03 Mar 2010 08:19:26 -0500
Received: from ey-out-1920.google.com ([74.125.78.150]:29854)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <rth7680@gmail.com>) id 1NmoTy-0007LO-36
	for qemu-devel@nongnu.org; Wed, 03 Mar 2010 08:19:22 -0500
Received: by ey-out-1920.google.com with SMTP id 5so910293eyb.14
	for <qemu-devel@nongnu.org>; Wed, 03 Mar 2010 05:19:13 -0800 (PST)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <4B8E6181.7010104@twiddle.net>
Date: Wed, 03 Mar 2010 14:17:53 +0100
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 3/4] Fix signal handling for ColdFire
References: <4B8C133D.2030900@codesourcery.com>
	<4B8C1660.5080009@codesourcery.com>
In-Reply-To: <4B8C1660.5080009@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Maxim Kuvyrkov <maxim@codesourcery.com>
Cc: qemu-devel@nongnu.org

> +    float64	sc_fpregs[2];	/* room for two fp registers */
...
> -    int f_fpcntl[3];
> -    int f_fpregs[8*3];
> +    uint32_t	f_fpcntl[3];
> +    float64	f_fpregs[8];

Surely these float64 uses are incorrect.  The kernel uses 3*int
at both of these places, which matches up with the 96-bit values
in the regular m68k fpu.


r~