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

2020-09-27 Thread Nikolay Nikolov via fpc-devel
On 9/28/20 12:30 AM, Tomas Hajny via fpc-devel wrote: On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote: 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

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

2020-09-27 Thread Marco van de Voort via fpc-devel
Op 2020-09-27 om 18:21 schreef Florian Klämpfl via fpc-devel: 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

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

2020-09-27 Thread Tomas Hajny via fpc-devel
On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote: 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 >

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 22:12 schrieb denisgolovan: Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Not for 80 bit extended, but it would be the clean solution with float128 support being optional in some architectures (RiscV, Sparc64, PPC64). So if we change it, we should do it right as 80

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

2020-09-27 Thread denisgolovan via fpc-devel
> Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: >> Not for 80 bit extended, but it would be the clean solution with >> float128 support being optional in some architectures (RiscV, Sparc64, >> PPC64). So if we change it, we should do it right as 80 Bit has the same >> problem:

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 22:03 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions): - there

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions): - there are little libraries being really IEEE compliant for float128 -

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions): - there are little libraries being really IEEE compliant for float128 - if they are IEEE compliant, their license does not allow to

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

2020-09-27 Thread denisgolovan via fpc-devel
> See above. It perfectly shows why it is frightening (not the basic > stuff, but the transcendent functions): > - there are little libraries being really IEEE compliant for float128 > - if they are IEEE compliant, their license does not allow to use the > code in the FPC rtl. Ok, the license is

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 20:57 schrieb denisgolovan via fpc-devel: Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel: So we would need softfloat extended support. This is doable with one major obstacle: the "irrational" functions like ld, sin etc.: they need precise enough implementations for 80

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

2020-09-27 Thread denisgolovan via fpc-devel
> Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel: > So we would need softfloat extended support. This is doable with one > major obstacle: the "irrational" functions like ld, sin etc.: they need > precise enough implementations for 80 bit (actually, just adding and > using in the

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel: 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

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel
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 > schrieb am So., 27. Sep. 2020, 07:50:     That last quote

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
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 > schrieb am So., 27. Sep. 2020, 07:50: That last quote is absolute BS, to be very frank. There is no reason

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel
On 9/27/20 7:03 PM, Martin Frb via fpc-devel wrote: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 2020, 07:50: That last quote is absolute BS, to be very frank. There is no reason

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

2020-09-27 Thread Martin Frb via fpc-devel
On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > 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

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel
On 9/27/20 10:48 AM, Florian Klämpfl via fpc-devel wrote: As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else. Yes. And unlike some other compilers, we don't exhaust our 32-bit address space during compilation or linking of very

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

2020-09-27 Thread Bart via fpc-devel
On Sun, Sep 27, 2020 at 3:06 PM Florian Klämpfl via fpc-devel wrote: > Thanks, fixed. Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

2020-09-27 Thread Florian Klämpfl via fpc-devel
Am 18.09.20 um 22:50 schrieb Bart via fpc-devel: Hi, In unit math.pp you can find this comment: 510 { returns random values with gaussian distribution } 511

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

2020-09-27 Thread Florian Klämpfl via fpc-devel
As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Sven Barth via fpc-devel
Ben Grasset via fpc-devel 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