[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?
Sven Barth
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:
>>
>> [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.
>>
>>
>> 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
> compile-time.
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
> compiler.
> Maybe constant-propagation will be the same at a levels of
> optimization....
>
> But, also none functional changes such as
>
> const c = extended(1.234567997807)
> var a, b: extended;
> begin
> 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.
Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220112/1557e4a2/attachment.htm>
More information about the fpc-devel
mailing list