Re: critical floating point incompatibility
On 2009-Jan-28 11:24:21 -0800, Bakul Shah ba...@bitblocks.com wrote: On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds 32 bit binaries. The following script makes it as easy to do so on a 64 bit FreeBSD -- at least on the few programs I tried. Ideally the right magic needs to be folded in gcc's builtin specs. #!/bin/sh args=/usr/bin/cc while [ .$1 != . ] do a=$1; shift case $a in -m32) args=$args -B/usr/lib32 -I/usr/include32 -m32;; *) args=$args $a;; esac done $args You also need to manually populate /usr/include32 since it doesn't exist by default and may still get bitten by stuff in /usr/local/include. Do you have a script (or installworld patches) to do this? amd64/112215 includes a first attempt at updating the gcc specs (though it's missing the include handling), as well as some of the remaining problems. Ideally x86_64 platforms run *all* i386 programs (that don't depend on a 32 bit kernel). Agreed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEBGdlUAosU.pgp Description: PGP signature
cc -m32 (was Re: critical floating point incompatibility
On Fri, 30 Jan 2009 05:44:00 +1100 Peter Jeremy peterjer...@optushome.com.au wrote: On 2009-Jan-28 11:24:21 -0800, Bakul Shah ba...@bitblocks.com wrote: On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds 32 bit binaries. The following script makes it as easy to do so on a 64 bit FreeBSD -- at least on the few programs I tried. Ideally the right magic needs to be folded in gcc's builtin specs. #!/bin/sh args=3D/usr/bin/cc while [ .$1 !=3D . ] do a=3D$1; shift case $a in -m32) args=3D$args -B/usr/lib32 -I/usr/include32 -m32;; *) args=3D$args $a;; esac done $args You also need to manually populate /usr/include32 since it doesn't exist by default and may still get bitten by stuff in /usr/local/include. Do you have a script (or installworld patches) to do this? Yes, includes for native programs will may cause trouble -- but you can't use -nostdinc (as that would take away that feature from a user), which is why this needs to be in the gcc specs. I don't have a script as I just copied include directories from a i386 system. But a script would be better. This script was an initial stab at proper -m32 support and needs more work. I will be happy to work with you or anyone else to make this happen. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: critical floating point incompatibility
On Mon, 26 Jan 2009 16:51:28 EST John Baldwin j...@freebsd.org wrote:
On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote:
Peter Jeremy peterjer...@optushome.com.au wrote:
On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote:
The default setting of the x87 floating point control word on the i386
port is 0x127F. Among other things, this value sets the precision
control to double precision. The default setting of the x87 floating
point control word on the AMD64 is 0x37F.
...
It seems clear that the right thing to do is to set the floating point
environment to the i386 default for i386 binaries. Is the current
behavior intended?
I believe this is an oversight. See the thread beginning
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html
From reading Bruce's last message in that thread, seems to me
may be default for 64bit binaries should be the same as on
i386. Anyone wanting different behavior can always call
fpsetprec() etc.
I think the fix is to change __INITIAL_FPUCW__ in
/sys/amd64/include/fpu.h to 0x127F like on i386.
I think this shall be done for 32-bit processes only, or we get into
another ABI breaking nightmare.
How about something like this: (Carl, can you please test this?)
Your patch works fine on a recent -current. Here is a
program Carl had sent me more than a year ago for testing
this. May be some varition of it can be added to
compatibility tests.
#include stdio.h
int main(void)
{
unsigned short cw;
__asm__ __volatile__ (fnstcw %0:=m(*cw));
printf(cw=%#x\n, cw);
return 0;
}
-- bakul
PS:
tangent
On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds
32 bit binaries. The following script makes it as easy to do
so on a 64 bit FreeBSD -- at least on the few programs I
tried. Ideally the right magic needs to be folded in gcc's
builtin specs.
#!/bin/sh
args=/usr/bin/cc
while [ .$1 != . ]
do
a=$1; shift
case $a in
-m32) args=$args -B/usr/lib32 -I/usr/include32 -m32;;
*) args=$args $a;;
esac
done
$args
Ideally x86_64 platforms run *all* i386 programs (that don't
depend on a 32 bit kernel).
/tangent
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: critical floating point incompatibility
On Wednesday 28 January 2009 2:24:21 pm Bakul Shah wrote:
On Mon, 26 Jan 2009 16:51:28 EST John Baldwin j...@freebsd.org wrote:
On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote:
Peter Jeremy peterjer...@optushome.com.au wrote:
On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote:
The default setting of the x87 floating point control word on the
i386
port is 0x127F. Among other things, this value sets the precision
control to double precision. The default setting of the x87
floating
point control word on the AMD64 is 0x37F.
...
It seems clear that the right thing to do is to set the floating
point
environment to the i386 default for i386 binaries. Is the current
behavior intended?
I believe this is an oversight. See the thread beginning
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html
From reading Bruce's last message in that thread, seems to me
may be default for 64bit binaries should be the same as on
i386. Anyone wanting different behavior can always call
fpsetprec() etc.
I think the fix is to change __INITIAL_FPUCW__ in
/sys/amd64/include/fpu.h to 0x127F like on i386.
I think this shall be done for 32-bit processes only, or we get into
another ABI breaking nightmare.
How about something like this: (Carl, can you please test this?)
Your patch works fine on a recent -current. Here is a
program Carl had sent me more than a year ago for testing
this. May be some varition of it can be added to
compatibility tests.
#include stdio.h
int main(void)
{
unsigned short cw;
__asm__ __volatile__ (fnstcw %0:=m(*cw));
printf(cw=%#x\n, cw);
return 0;
}
-- bakul
Cool, thanks for testing!
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: critical floating point incompatibility
On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote:
Peter Jeremy peterjer...@optushome.com.au wrote:
On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote:
The default setting of the x87 floating point control word on the i386
port is 0x127F. Among other things, this value sets the precision
control to double precision. The default setting of the x87 floating
point control word on the AMD64 is 0x37F.
...
It seems clear that the right thing to do is to set the floating point
environment to the i386 default for i386 binaries. Is the current
behavior intended?
I believe this is an oversight. See the thread beginning
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html
From reading Bruce's last message in that thread, seems to me
may be default for 64bit binaries should be the same as on
i386. Anyone wanting different behavior can always call
fpsetprec() etc.
I think the fix is to change __INITIAL_FPUCW__ in
/sys/amd64/include/fpu.h to 0x127F like on i386.
I think this shall be done for 32-bit processes only, or we get into
another ABI breaking nightmare.
How about something like this: (Carl, can you please test this?)
http://www.FreeBSD.org/~jhb/patches/amd64_fpu_i386.patch
--- //depot/vendor/freebsd/src/sys/amd64/amd64/fpu.c2006/06/19 22:39:16
+++ //depot/user/jhb/acpipci/amd64/amd64/fpu.c 2009/01/26 21:47:49
@@ -391,6 +391,7 @@
{
struct pcb *pcb;
register_t s;
+ u_short control;
if (PCPU_GET(fpcurthread) == curthread) {
printf(fpudna: fpcurthread == curthread %d times\n,
@@ -421,6 +422,10 @@
* explicitly load sanitized registers.
*/
fxrstor(fpu_cleanstate);
+ if (pcb-pcb_flags PCB_32BIT) {
+ control = __INITIAL_FPUCW_I386__;
+ fldcw(control);
+ }
pcb-pcb_flags |= PCB_FPUINITDONE;
} else
fxrstor(pcb-pcb_save);
--- //depot/vendor/freebsd/src/sys/amd64/include/fpu.h 2004/04/05 21:30:47
+++ //depot/user/jhb/acpipci/amd64/include/fpu.h2009/01/26 21:47:49
@@ -92,6 +92,7 @@
* SSE2 based math. For FreeBSD/amd64, we go with the default settings.
*/
#define__INITIAL_FPUCW__ 0x037F
+#define__INITIAL_FPUCW_I386__ 0x127F
#define__INITIAL_MXCSR__ 0x1F80
#define__INITIAL_MXCSR_MASK__ 0xFFBF
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: critical floating point incompatibility
On 12/20/07, Peter Jeremy [EMAIL PROTECTED] wrote: I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html Thanks for the pointer into the -stable mailing list. The incorrect precision control bits is a serious quality of life issue for those of us who care about consistent numerical computations and the backward compatibility of our FreeBSD object code. Is there an active community of users who care about numerics on FreeBSD? At any rate, I searched the PR database for a bug related to the incorrect control word setting but came up empty handed. If nothing has been filed to date I will go ahead and submit a PR. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: critical floating point incompatibility
On Fri, Dec 21, 2007 at 03:09:33AM -0800, Carl Shapiro wrote: On 12/20/07, Peter Jeremy [EMAIL PROTECTED] wrote: I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html Thanks for the pointer into the -stable mailing list. The incorrect precision control bits is a serious quality of life issue for those of us who care about consistent numerical computations and the backward compatibility of our FreeBSD object code. Is there an active community of users who care about numerics on FreeBSD? There are certainly people who care about numerics on FreeBSD. Most of the floating-point related discussions seem to happen on the freebsd-standards@ mailing list. You could check the archives of that list. At any rate, I searched the PR database for a bug related to the incorrect control word setting but came up empty handed. If nothing has been filed to date I will go ahead and submit a PR. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: critical floating point incompatibility
Carl Shapiro wrote: On 12/20/07, Peter Jeremy [EMAIL PROTECTED] wrote: I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html Thanks for the pointer into the -stable mailing list. The incorrect precision control bits is a serious quality of life issue for those of us who care about consistent numerical computations and the backward compatibility of our FreeBSD object code. Is there an active community of users who care about numerics on FreeBSD? At any rate, I searched the PR database for a bug related to the incorrect control word setting but came up empty handed. If nothing has been filed to date I will go ahead and submit a PR. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] go ahead and submit the PR I'm guessing a combination of Peter Wemm and Bruce Evans would be able to decide on the right course of action. (CC'd) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: critical floating point incompatibility
Peter Jeremy [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: The default setting of the x87 floating point control word on the i386 port is 0x127F. Among other things, this value sets the precision control to double precision. The default setting of the x87 floating point control word on the AMD64 is 0x37F. ... It seems clear that the right thing to do is to set the floating point environment to the i386 default for i386 binaries. Is the current behavior intended? I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html From reading Bruce's last message in that thread, seems to me may be default for 64bit binaries should be the same as on i386. Anyone wanting different behavior can always call fpsetprec() etc. I think the fix is to change __INITIAL_FPUCW__ in /sys/amd64/include/fpu.h to 0x127F like on i386. Also, while at it, comments above this constant in this file and above __INITIAL_NPXCW__ in /sys/i386/include/npx.h needs to reflect what was chosen and why. Filing a PR would help ensure this doesn't get lost. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: critical floating point incompatibility
On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote: Peter Jeremy [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: The default setting of the x87 floating point control word on the i386 port is 0x127F. Among other things, this value sets the precision control to double precision. The default setting of the x87 floating point control word on the AMD64 is 0x37F. ... It seems clear that the right thing to do is to set the floating point environment to the i386 default for i386 binaries. Is the current behavior intended? I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html From reading Bruce's last message in that thread, seems to me may be default for 64bit binaries should be the same as on i386. Anyone wanting different behavior can always call fpsetprec() etc. I think the fix is to change __INITIAL_FPUCW__ in /sys/amd64/include/fpu.h to 0x127F like on i386. I think this shall be done for 32-bit processes only, or we get into another ABI breaking nightmare. Also, while at it, comments above this constant in this file and above __INITIAL_NPXCW__ in /sys/i386/include/npx.h needs to reflect what was chosen and why. Filing a PR would help ensure this doesn't get lost. pgpgY9y0FQaFE.pgp Description: PGP signature
Re: critical floating point incompatibility
On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: The default setting of the x87 floating point control word on the i386 port is 0x127F. Among other things, this value sets the precision control to double precision. The default setting of the x87 floating point control word on the AMD64 is 0x37F. ... It seems clear that the right thing to do is to set the floating point environment to the i386 default for i386 binaries. Is the current behavior intended? I believe this is an oversight. See the thread beginning http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpuVHlsgX4TJ.pgp Description: PGP signature
critical floating point incompatibility
Developers, There is a critical incompatibility between the floating point environment of the 32-bit compatibility environment of AMD64 systems and a genuine i386 system. The default setting of the x87 floating point control word on the i386 port is 0x127F. Among other things, this value sets the precision control to double precision. The default setting of the x87 floating point control word on the AMD64 is 0x37F. This value sets the precision control to double-extended precision. Since the AMD64 port uses SSE2 instructions for single and double precision arithmetic (thereby reserving the x87 for double-extended precision) this is a reasonable setting. Unfortunately, when a 32-bit binary is run under compatibility on an AMD64 system, the floating point control word is 0x37F, not 0x127F. 32-bit binaries do not expect the floating point environment to be in this state. The net effect is that all but the most trivial programs using x87 floating point arithmetic instructions will produce different values when run on a native i386 system than when run under compatibility on a 64-bit system! It seems clear that the right thing to do is to set the floating point environment to the i386 default for i386 binaries. Is the current behavior intended? Carl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
