[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?
pascaldragon at googlemail.com
Wed Jan 12 23:20:34 CET 2022
Am 12.01.2022 um 19:26 schrieb Martin Frb via fpc-devel:
> On 12/01/2022 18:48, Sven Barth via fpc-devel wrote:
>>  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.
>> 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.
> You completely missed the point.
> I was NOT comparing Win vs Linux
> I wrote
>> 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.
> Note the 2nd line.
> - The exact same pascal code
> - The exact same 32-bit ppcx64.exe
> - the exact same target: Only compiling to 64-bit Windows exe
> Changing only compiler options (e.g. optimizations), could possible
> trigger a behavioural change in the resulting exe.
> Because some calculation changed between being compiled to run-time or
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.
> => ok, I have not deep enough insight into the optimizer, maybe
> constant-propagation is 100% independent of any option passed to the
> Maybe constant-propagation will be the same at a levels of
> But, also none functional changes such as
> const c = extended(1.234567997807)
> var a, b: extended;
> a := c;
> b := c + a;
> changed to
> b:= c+c;
> This is still the same code. There is no reason for a user to assume
> the result should change.
> But, depending on the code in between, I have seen cases were "c+a"
> was done run-time.
> While "c+c" should be compile time.
> So, maybe it's not byte by byte the same pascal code. But from a
> functional point of view, it is the same code.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel