Am 18.02.20 um 13:26 schrieb Alexander Hofmann via fpc-devel:
Dear all,
while investigating a bug in an application designed for ARM with
floating point emulation enabled, I stumbled upon the following problem:
Thanks for reporting and providing a fix, I committed it in r44235.
__
It is a bit more complex than that: using the softfloat ABI does not
necessarily mean softfloat is used.
The ABI can still use hardware fp. And that is the case here, I suspect.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.fre
Hi,
Am 19.02.20 um 09:08 schrieb thaddy:
> Raspberry Pi, what OS, because you write armsf and the default on
> Raspbian (and other major distro's) is armhf.
Raspbian, which is armhf, yes.
The application is based on the hard-float ABI (just checked with
readelf -h). Still it is using the soft-fl
Raspberry Pi, what OS, because you write armsf and the default on
Raspbian (and other major distro's) is armhf.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Thanks...
On Tue, Feb 18, 2020 at 8:36 PM Alexander Hofmann via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Dear all,
>
> while investigating a bug in an application designed for ARM with floating
> point emulation enabled, I stumbled upon the following problem:
>
> When rounding large n
Dear all,
while investigating a bug in an application designed for ARM with
floating point emulation enabled, I stumbled upon the following problem:
When rounding large numbers to int64, some actually get rounded to
something negative, e.g:
round(1.5000E+018) => 150
