[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