Dear fpc developers,

Let me submit a divison bug:

When a floating point constant which fits into single precision is divided by integer variable, the result is assumed to be a single-precision number.

program div5;
var  five:integer=5;
begin
    writeln(1.0/five);
    writeln(1.0/five-1/five);
end.

versions where problem spotted:
3.0.4 [2019/10/27] for x86_64 on windows
3.0.4+dfsg-18ubuntu2 [2018/08/29] for x86_64

older version with no problem:
fpc 2.6.4 i386-win32 is OK

Thanks

T.

Tomas L. wrote

When a floating point constant which fits into single precision is divided by integer variable, the result is assumed to be a single-precision number. 

Indeed, this is by design. See
https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for how to explicitly specify a different precision.

Jonas

Indeed, this is by design. See https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for how to explicitly specify a different precision.

That was long before the change Tomas discovered.

The gotcha here is about your fix to
<https://bugs.freepascal.org/view.php?id=25121>, which together with the one you linked made runtime and compile time evaluation the same, at the expense of specifically breaking Delphi compat.

But since then, FPC sees Single / Int2Single = Single, with no high precision intermediates.
There was either a bug or a thread here about the code that broke and some issues with explicit casts also not helping, but I can't seem to locate either.

Best,

Sebastian

As the delphi behavior is very i386/x86-64 specific, FPC deviates from it (not to mention that the non-i386 behavior was implemented years before a non-i386 delphi was available).

Florian Klämpfl wrote

As the delphi behavior is very i386/x86-64 specific, FPC deviates from it (not to mention that the non-i386 behavior was implemented years before a non-i386 delphi was available).

Actually, back then I thought I fixed the (dynamic) behaviour at least in a Delphi-compatible way: https://bugs.freepascal.org/view.php?id=7179

I don't remember anymore on what test this assumption was based though.

Jonas

Florian Klämpfl wrote

As the delphi behavior is very i386/x86-64 specific, FPC deviates from it (not to mention that the non-i386 behavior was implemented years before a non-i386 delphi was available).

Jup, that's what I meant with "made runtime and compile time evaluation the same". Without that change, cross and native compilers would have different constant evaluation, which is obviously not good either.

Best,
Sebastian

Op 2019-12-08 om 18:46 schreef Jonas Maebe:

Afaik Delphi x64 doesn't do single math at all, and converts each load/store from single to double, and only operates on doubles

Yes. It basically mimics the i386 behavior: doing all operations with the highest available precision.