[fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov]

On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote:
> Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel:
>> On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
>>> Ben Grasset via fpc-devel <fpc-devel at lists.freepascal.org 
>>> <mailto:fpc-devel at lists.freepascal.org>> schrieb am So., 27. Sep. 
>>> 2020, 07:50:
>>>
>>>     That last quote is absolute BS, to be very frank. There is no
>>>     reason whatsoever not to use a natively-64-bit copy of FPC if
>>>     running a natively-64-bit copy of Windows, and there hasn't been
>>>     for well over half a decade at this point.
>>>
>>>
>>> Yes, there is a reason: you can not build a i8086 or i386 cross 
>>> compiler with the Win64 compiler (or any non-x86 compiler to be 
>>> fair) due to missing Extended support. Thus the majority of the FPC 
>>> Core team considers the Win64 compiler as inferior and also 
>>> unnecessary cause the 32-bit one works just as well on that platform.
>>>
>> Just my 2 cents.
>>
>> Well, one the one hand, native 64 bit is only really important if it 
>> can do something that 32 bit can not do. (faster, bigger sources, ....).
>>
>> On the other hand, not everyone needs a win64 to win32 cross 
>> compiler. And if they do, a native 32bit compiler can be renamed and 
>> will happily serve as such a cross compiler. (But that is not a must 
>> be included / such workarounds may not be wanted, especially since 
>> they might cause repeated extra work)
>>
>> So the question here is/are imho about the work it takes to amend the 
>> release-build process (i.e. update the scripts). And then the amount 
>> of extra time needed for each release (build and testing).
>
> The thing is: we would distribute a compiler (the x86_64-win64 one) 
> which claims to be able to compile to e.g. to x86_64-linux, but it 
> would generate programs which might behave differently than natively 
> compiled ones as float constants are handled internally different.

And in this particular case, "different" means "less accurate", due to 
rounding errors, caused by compile time conversion of 80-bit extended 
float constants to 64-bit double precision constants. And "less 
accurate" is bad. :)

Nikolay