Actually, that test is wrong, because the 32bit code will use Extended float literals instead of Double. If you force it to use double in 32bit you get the same result.
If you want to use SSE instructions, you will need to add additional checks to see if the value will fit into an integer before you use the SSE instructions. From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf Of Sven Barth via fpc-devel Sent: Saturday, 28 April 2018 03:33 To: FPC developers' list <fpc-devel@lists.freepascal.org> Cc: Sven Barth <pascaldra...@googlemail.com> Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64 Thorsten Engler <thorsten.eng...@gmx.net <mailto:thorsten.eng...@gmx.net> > schrieb am Fr., 27. Apr. 2018, 18:48: For what it’s worth, Delphi simply decided to give up on doing it correctly and silently fail if the double is too large to fit in an Int64. WriteLn(Frac(1e15+0.5)); WriteLn(Frac(1e16+0.5)); When executed in 32bit code, returns: 5.00000000000000E-0001 5.00000000000000E-0001 And when executed in 64bit code, returns: 5.00000000000000E-0001 0.00000000000000E+0000 Whoever had the *brilliant* idea to deprecate the FPU in 64bit mode should be shoot and quartered, not necessarily in that order. 64bit code is basically useless if you want to do anything meaningful with floats that are larger than fits into an int64. Ehm, what does the depreciation of the FPU have to do with that the floats are too large for an Int64? Extended would only allow for even larger values that would not fit. And all other functionality "simply" needs to be implemented correctly using the "new" SSE functionality, which however is not without its pitfalls as we have seen. Regards, Sven
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
