[issue18062] m68k FPU precision issue

Stefan Krah added the comment: This should be fixed now. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> HAVE_PY_SET_53BIT_PRECISION for m68k type: -> behavior ___ Python tracker

[issue18062] m68k FPU precision issue

Stefan Krah added the comment: Can we somehow merge this issue with #20904? -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue18062] m68k FPU precision issue

mirabilos added the comment: Eero Tamminen dixit: >> > Now as additional data point, UAE/WinUAE/etc. would be interesting. > >I built the test with fpu_control.h header from eglibc, using >Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib. When it's Nice ;) >I.e. it seems that WinUAE FPU e

[issue18062] m68k FPU precision issue

mirabilos added the comment: Laurent Vivier dixit: > For the "etc" ;-) , in Qemu, I have: Hm, I thought qemu did not emulate an MMU? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was rea

[issue18062] m68k FPU precision issue

mirabilos added the comment: Laurent Vivier dixit: > BTW, the result on a real CPU (68040) is : 68881 even ;-) > test#1 fail: 1.0E+00 > test#2 fail: 1.00040E+16 > changing FPU control word from to 0080 => 0080 > test#1 good: 1.00022E+00

[issue18062] m68k FPU precision issue

mirabilos added the comment: Mark Dickinson dixit: >If there are tests failing with the 'legacy' mode, that may just >indicate buggy tests that haven't been properly marked as depending on >the short float repr. (E.g., by decorating with I think that’s what we’re seeing here. Python 3.3.1 (def

[issue18062] m68k FPU precision issue

Andreas Schwab added the comment: Thorsten Glaser writes: > root@ara3:~ # ./a.out > test#1 fail: 1.0E+00 > test#2 fail: 1.00040E+16 > changing FPU control word from to 0080 => 0080 > test#1 fail: 1.0E+00 > test#2 fail: 1.0

[issue18062] m68k FPU precision issue

Mark Dickinson added the comment: It's also an option not to use dtoa.c: Python still has fallback code that uses the OS double <-> char* conversions for the case where the configuration step can't figure out how to change the FPU control word. In that case compilation should still succeed,

[issue18062] m68k FPU precision issue

Mark Dickinson added the comment: > The problem with changing the FPUCW on i387 is that it changes > from 64/15 bit mantissa/exponent to 53/15 bit which is still > not the 53/11 bit of IEEE double, so you *still* get double- > rounding issues (with denormal numbers only, I guess) because > the in

[issue18062] m68k FPU precision issue

mirabilos added the comment: Stefan Krah dixit: >> fixing this in general would allow keeping the FPUCW on i387 unchanged too. > >Actually dtoa.c (which is used on i387) explicitly requires to change >the control word. Right. By fixing the “older” code, i386 is not required to change the FPUCW

[issue18062] m68k FPU precision issue

mirabilos added the comment: mirabilos dixit: >mirabilos added the comment: >Yes, that’s precisely what’s not working on the most widespread >emulator, at the very least. (I have working code for that, in >three(!) variants, but it just ignores those requests to change >precision.) Here’s the

[issue18062] m68k FPU precision issue

Stefan Krah added the comment: I forgot to comment on this: > fixing this in general would allow keeping the FPUCW on i387 unchanged too. Actually dtoa.c (which is used on i387) explicitly requires to change the control word. Looking at the test results, it seems to me that a couple of tests

[issue18062] m68k FPU precision issue

mirabilos added the comment: > > We do not want to change it to 64-bit because it’s not supported > > in all environments. > Does this also apply to changing the precision temporarily? Yes, that’s precisely what’s not working on the most widespread emulator, at the very least. (I have working

[issue18062] m68k FPU precision issue

Stefan Krah added the comment: > We do not want to change it to 64-bit because it’s not supported in all > environments. Does this also apply to changing the precision temporarily? Because that is what happens for other platforms, see Include/pyport.h: HAVE_PY_SET_53BIT_PRECISION _PY_SET_53BI

[issue18062] m68k FPU precision issue

New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it’s not supported in all environments. Can probably be reproduced on i38