<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 12.01.2022 um 19:26 schrieb Martin
Frb via fpc-devel:<br>
</div>
<blockquote type="cite"
cite="mid:ba1ae377-3ae1-08e3-2a36-e0d42bbd4911@mfriebe.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 12/01/2022 18:48, Sven Barth via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFMUeB8Mhq5KQeN5GiRA5uSp3Yq5yW4Yrqw0Bie6vYzeB6y7NQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="auto"><br>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> [2]
From the users view "random", in that the user can not
predict all <br>
the factors that will affect the selection.<br>
<br>
<br>
Currently the user must be prepared for the latter.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">No, it is deterministic, it's simply different
from a native x86_64-linux compilation or one from Win32 as
mentioned above and that is bad.</div>
<br>
</div>
</blockquote>
<br>
You completely missed the point.<br>
I was NOT comparing Win vs Linux<br>
<br>
I wrote<br>
<blockquote type="cite">And this is not comparing the behaviour
between the Linux and Windows
exe (both 64 bit). I agree that different behaviour must be expected.
<br>
This is the behaviour between compiling the same code, with the
same compiler, several times for the same target win-64. </blockquote>
<br>
Note the 2nd line.<br>
<br>
- The exact same pascal code <br>
- The exact same 32-bit ppcx64.exe<br>
- the exact same target: Only compiling to 64-bit Windows exe <br>
<br>
Changing only compiler options (e.g. optimizations), could
possible trigger a behavioural change in the resulting exe.<br>
Because some calculation changed between being compiled to
run-time or compile-time. <br>
</blockquote>
<br>
No, at least not in the general case if the optimizations are bug
free. The only optimizations that might lead to behavior difference
with the above mentioned points are those of -O4 (cause those might
make use of undefined behavior) or $FASTMATH and both are true for
any platform.<br>
<br>
<blockquote type="cite"
cite="mid:ba1ae377-3ae1-08e3-2a36-e0d42bbd4911@mfriebe.de"> =>
ok, I have not deep enough insight into the optimizer, maybe
constant-propagation is 100% independent of any option passed to
the compiler.<br>
Maybe constant-propagation will be the same at a levels of
optimization....<br>
<br>
But, also none functional changes such as<br>
<br>
const c = extended(1.234567997807)<br>
var a, b: extended;<br>
begin<br>
a := c;<br>
...<br>
b := c + a;<br>
<br>
changed to <br>
b:= c+c;<br>
<br>
This is still the same code. There is no reason for a user to
assume the result should change.<br>
But, depending on the code in between, I have seen cases were
"c+a" was done run-time.<br>
While "c+c" should be compile time.<br>
<br>
So, maybe it's not byte by byte the same pascal code. But from a
functional point of view, it is the same code.<br>
</blockquote>
<br>
When compiling from a target supporting Extended to one only
supporting Double there isn't a loss of precision when calculating
values at compile time. The other way around however, there *is* and
that is the more crucial problem.<br>
<br>
Regards,<br>
Sven<br>
</body>
</html>