[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?

[Martin Frb]

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" ?


Of course if the above conclusions are correct, the choice for such code is
- sometimes (depending on various hard to predict factors) differ from 
32 bit version
    i.e. compiling to 64 bit: ending up, at different times, with either 
one of two (or more) different behaviours
- always differ from the 32bit version
    i.e. compiling to 64 bit: ending up, with one and only one 
behaviours (although diff from 32 bit)