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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
