Auto-update compilers option

[mdbs99]

I've installed FPC/Lazarus with cross-compile from Windows to Linux. I had an issue in one system that the binaries to cross-compiled could be wrong - cause the same sources do not have issues if compiled in another machine, same FPC/Laz revisions.

My question is: clicking on "Auto-update compilers" fpcupdeluxe will update FPC binaries and cross binaries, getting the fresh files when it will search?

[synopse]

to be more precise, the following line didn't compile as expected: compiling if currencyvariable = 100 then assemble into

        fild    qword ptr [rbp-8CH]                     ; 05C0 _ DF. AD, FFFFFF74
        mov     rax, qword ptr [_$CLIFRYCLIENT$_Ld27]   ; 05C6 _ 48: 8B. 05, 00000000(GOT r)
        fild    qword ptr [rax]                         ; 05CD _ DF. 28
        fcomip  st(0), st(1)                            ; 05CF _ DF. F1
        fstp    st(0)                                   ; 05D1 _ DD. D8
        jpe     ?_060                                   ; 05D3 _ 7A, 02

On all compilers, which sounds fair enough.

On most compilers, it generates the following constant:

_$CLIFRYCLIENT$_Ld27 label qword
        dq 00000000000F4240H                            ; 0000 _ 00000000000F4240 

which is correct, since 00000000000F4240 = ‭1000000‬ = 100.00 encoded as currency

but on marcos (with the very same SVN revision of FPC)

_$CLIFRYCLIENT$_Ld27 label qword
        dq 412E848000000000H                            ; 0000 _ 412E848000000000 

which is not correct, since 412E848000000000 is 1000000 but encoded as double, not as currency/int64

This is by cross-compiling from Windows to Linux on all computers (Marcos and mine).

[LongDirtyAnimAlf]

@mdbs99 The installer and auto-updater of cross-compiler(s) does NOT change the sources ! The existing sources will be used. So, the moment you update your FPC (sources), the FPC compiler itself and the cross-compilers will be out-of-sync. The normal way of actions should therefor be: 1: Update FPC (and Lazarus). 2: Update cross-compilers.

[LongDirtyAnimAlf]

@synopse This is very strange. There is only one cause that I can think of: One PC has the win32 version of FPC (and fpcupdeluxe) installed. And the other PC has the win64 version of FPC (and fpcupdeluxe) installed. But I guess this will not be the case. If not , I am lost. But will try to take a closer look.

[mdbs99]

@LongDirtyAnimAlf

The installer and auto-updater of cross-compiler(s) does NOT change the sources ! The existing sources will be used.

I understood like that. My question is about the pre-binaries to use in cross-compile, which I'm thinking this is my issue. As I understand, fpcupdeluxe will download that binaries, right? Let suppose one of these binaries is wrong and the FPC team need to update it. How can I get this new binary or binaries using fpcupdeluxe?

[mdbs99]

@LongDirtyAnimAlf @synopse For your information, in my case there is just win64 installed with cross-compile from Win to Linux 64.

[synopse]

so perhaps this is the root cause I installed FPC and Lazarus Win32 so that I could compile for Win32 and Win64. IIRC a Win64 FPC is not able to compile for Win32, and is not able to use x87 instructions - so perhaps there is a bug with a Win64 FPC when using currency values.

There is a win64 cannot compile i386 or i8086 compiler and ifeq ($(OS_SOURCE),win64) EXCLUDE_80BIT_TARGETS=1 in compiler\Makefile.fpc - so perhaps there is a bug when FPC_CURRENCY_IS_INT64 is defined.

[LongDirtyAnimAlf]

@synopse Fpcupdeluxe enables the whole 80bit softfloat library on Win64. Only with this setting, it is possible to cross-compile towards 32bit (Intel) targets.

[LongDirtyAnimAlf]

@mdbs99 Fpcupdeluxe only downloads the binary tools that are needed to build a cross-compiler. No FPC binaries are used, except for the bootstrapper that was used to build FPC itself. And this bootstrapper is not used for building the cross-compilers.

[synopse]

Fpcupdeluxe enables the whole 80bit softfloat library on Win64.

? there is no need to emulate anything - the x87 instructions are there on the CPU, but just not used by the Win64 ABI - whereas on Linux, the x87 mode should be always on, not the MMX mode https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf

I guess under Win64, they didn't want to play with x87 extended constant propagation or pre-compilation, so they disabled it...

Only with this setting, it is possible to cross-compile towards 32bit (Intel) targets.

I guess using the Win32 compiler is the safer option

Anyway if it is confirmed that Win64 doesn't compile correctly if percent = 100 then for the Linux x86-64 target when percent is a currency (it is correct for the Win64 target and handle it as an integer), we will submit a bug request to the FPC team! :)

[mdbs99]

Both were right about win32 vs win64 - even that is weird, at least for me. After install the win32 version, then install a cross for i386-linux and x86_64-linux, I could cross-compiled for Linux x86_64 and got the same ASM as @synopse:

_$CLIFRYCLIENT$_Ld27 label qword
        dq 00000000000F4240H                            ; 0000 _ 00000000000F4240

Anyway if it is confirmed that Win64 doesn't compile correctly if percent = 100 then for the Linux x86-64 target when percent is a currency (it is correct for the Win64 target and handle it as an integer), we will submit a bug request to the FPC team! :)

So, it's confirmed! ;)

Thank you guys.