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

On Tue, Sep 29, 2020 at 3:00 PM Nikolay Nikolov via fpc-devel wrote: > >> fpc -Px86_64 hello.pas > > Doesn't that need a -TWin64 as well? > > It's not needed - Win64 is the default target of the windows-hosted > x86_64 crosscompiler. But it doesn't hurt if you add it. Hah! That will save me

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

On 9/28/2020 9:35 AM, Nikolay Nikolov via fpc-devel wrote: On 9/28/20 12:24 AM, Travis Siegel via fpc-devel wrote: How does one get a 64-bit version on windows.  When I try to run a 64-bit version on windows, I encounter an error, though I don't remember what that error is, since I've not

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

On 9/28/20 10:01 PM, Bart via fpc-devel wrote: On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel wrote: compile to win32 via: fpc -Pi386 hello.pas AFAIK a simple fpc hello.pas will do in that setup. Yes, that is true. The -Pi386 is optional in this case. and to win64 via:

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

On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel wrote: > compile to win32 via: > > fpc -Pi386 hello.pas AFAIK a simple fpc hello.pas will do in that setup. > and to win64 via: > > fpc -Px86_64 hello.pas Doesn't that need a -TWin64 as well? -- Bart

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

On 9/28/20 12:24 AM, Travis Siegel via fpc-devel wrote: How does one get a 64-bit version on windows.  When I try to run a 64-bit version on windows, I encounter an error, though I don't remember what that error is, since I've not tried it for a couple weeks.  I didn't even know there was a

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

Travis Siegel via fpc-devel schrieb am Mo., 28. Sep. 2020, 10:01: > But, in any case, if there's a way to get 64-bit versions on windows, I'd > like to know how. > Easiest: install a 64-bit Lazarus, it contains a 64-bit FPC. Other than that: download the source for your compiler version and

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

On 27.09.2020 23:45, Travis Siegel via fpc-devel wrote: On 9/27/2020 3:50 PM, Florian Klämpfl via fpc-devel wrote: - 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. I don't

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

On 9/27/2020 3:50 PM, Florian Klämpfl via fpc-devel wrote: - 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. I don't understand this statement. How does having all the required

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

How does one get a 64-bit version on windows.  When I try to run a 64-bit version on windows, I encounter an error, though I don't remember what that error is, since I've not tried it for a couple weeks.  I didn't even know there was a 64-bit windows version, because as mentioned below,

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

> Am 28.09.2020 um 00:32 schrieb Nikolay Nikolov via fpc-devel > : > > I don't have an exact answer, but I think higher precision is better, > compared to lower. You can not expect bitwise identical result, when using > floating point calculations anyway. For example AMD and Intel FPUs

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

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] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

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

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

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

Was browsing on the FPC wiki (that is, the actual wikipedia.com entry for FPC) today, and came across an edit someone had made in the "3.2.0" section that said the following: "FreePascal cannot be installed on macOS Catalina, and no known workaround exists." It then linked to an open issue on