[fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC website for the next release?

[Tomas Hajny]

On 2022-01-12 16:03, Martin Frb via fpc-devel wrote:
> On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote:
>> 
>>> - The problem is *NOT* a native 64 bit "ppcx64.exe"  ?
>>>    => 64 bit compiled targets don't require "extended" from the ppc,
>>> as they themself wont have support for it?
>> 
>> Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux 
>> (supported by the same compiler targetting 64-bit code) supports 
>> extended. This means that compiling source code with this compiler may 
>> result in a different binary as soon as there's e.g. an extended 
>> contstant included in the source code, or any compile-time 
>> calculations in this precision need to be performed.
> 
> Ok, I was too unspecific, I indeed just meant a 64-bit Window
> ppcx64.exe to compile a 64 bit target Windows app.
> 
> But indeed, I did not think about compile-time evaluations.
> Those will indeed differ.
> 
> Leaving the question if it is in that case actually desired that they
> are done in "extended" precision.
> Imagine some code (targeted at Win-64) that uses "extended" (which
> will at runtime become "double"? Or at least be less precise than
> "extended").
> 
> Now if that code, does some calculations with those values, and the
> code is written so the calculations happen at runtime => then the
> calculations are done at lower precision.
> This would potentially affect the result. I guess that would be
> expected behaviour.
> 
> But, if any change to the code (not even necessarily a functional
> change) would allow the compiler to do those calculations at compile
> time, then the value changes. And the entire behaviour of the app may
> change.
> Possible, this could even be a change just in optimization settings
> (or upgrading FPC), allowing the compiler to to propagate constants...
> 
> So does that mean, any code (that is to be compiled for Win-64bit) is
> considered "unstable" if it contains "extended" ?

Not necessarily - when targetting Win64, the user needs to be prepared 
for the lower precision. However, imagine that that the user compiles 
his source code for target x86_64-linux. The resulting binary and its 
output will be exactly the same if the source code is compiled (with the 
same options, etc.) on Linux or if it is compiled on Windows using a 
Win32 hosted compiler, but it will differ if using a Win64 hosted 
compiler. From compiler support point of view, this is an issue.

Tomas