[fpc-pascal] Loss of precision when using math.Max()

Florian Klämpfl florian at freepascal.org
Thu Jul 12 23:38:28 CEST 2018


Am 10.07.2018 um 19:35 schrieb Martok:
>>> I seem to remember that this was once documented somewhere for Delphi. Can't
>>> seem to find it though, so maybe it was a 3rd-party book? There is
>>> no hint of it
>>> in the FPC documentation, anyway.
>> As already noted, it is not necessary in DelphiAh sorry, I was wrong: misremembered Integer const evaluation, where you should
> cast the first part of the expression to Int64 if you want your expression to be
> evaluated as that instead of Integer. Completely different issue.
> 
> 
> The fix for #25121 doesn't seem like the best solution. The reported issue was
> with explicit casts, I think the truncation should rather be in
> ttypeconvnode.{typecheck_int_to_real, typecheck_real_to_real,
> typecheck_real_to_currency} ?
> 
> That would give bestreal-precision back to const evaluation *unless* the
> programmer explicitly casts to a lower precision? 

This will result in different results for runtime and compile time calculated expressions => bad idea.

> During Codegen, casting down
> happens anyway because of the storage requirements.
> 

I have added support for the directive $EXCESSPRECISION: it forces that all binary float operations are executed with 
the highest available precision available for the currently selected FPU.



More information about the fpc-pascal mailing list