[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 17:31, Tomas Hajny via fpc-devel wrote:
> On 2022-01-12 16:03, Martin Frb via fpc-devel wrote:
>>
>>
>> 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.

Ok. So a question of priority. (E.g., reducing maintenance on tests?)

Not to say, that due to ABI different registers may be used. Triggering 
different subsequent optimizations.....

And yes, I can see your point. That exact problem, that a bug in the 
optimizer manifested on windows, but not linux has cost me several 
weeks. (Because I could not get it with valgrind).
So, I do get, that trying to minimize such things, is very appealing.


-----------------

 >> when targetting Win64, the user needs to be prepared for the lower 
precision
Yes, but It is one thing to be prepared for:
- One (exactly one) "lower precision", and all behaviour (on that 
platform [1]) to be always according to that specific precision.

[1] on that platform, with that exact revision of the compiler.
      But with any compile options, and independent of none functional 
changes to the users code.

It is another thing to be prepared for
- A random[2] "precision" that will change depending on compiler options 
and/or seemingly unrelated changes in the user's code

[2] From the users view "random", in that the user can not predict all 
the factors that will affect the selection.


Currently the user must be prepared for the latter.

Because if for example anything changes that affects constant 
propagation, calculation may move from run to compile time, or vice 
versa. And with that the used "precision" for an individual calculation 
will change.
The user may not be able to predict under which conditions that happens. 
So for the user there are random changes to the behaviour of his program.

And this is not comparing the behaviour between the Linux and Windows 
exe (both 64 bit). I agree that different behaviour must be expected.
This is the behaviour between compiling the same code, with the same 
compiler, several times for the same target win-64.
Changing a compiler option, will/can change the behaviour of the 
resulting exe.

Such "optimization" depend changes normally happen, if
- the code has (hidden) bugs
- the code uses undocumented behaviour
But I believe "extended" is documented.....

-----
Just to say, I am not saying it has to be changed. Really does not 
matter to me.
Just trying to fully understand the matter, the possible side effects 
(of either path that can be taken), and so on.