Hi, On Thu, 20 Aug 2020, John Paul Adrian Glaubitz wrote:
> >>> If this also crashes, then I have to dig deeper to identify the problem, > >>> because 3.2.x will be with us for a while, and I'd like it to be built for > >>> Debian-m68k. > >> > >> It still fails with: > >> > >> numlib/units/m68k-linux/spe.s: Assembler messages: > >> numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point > >> number > >> spe.pas(1793) Error: Error while assembling exitcode 1 > >> spe.pas(1793) Fatal: There were 2 errors compiling module, stopping > >> Fatal: Compilation aborted > > > > Can you send me that spe.s file which fails to compile? > > See attached. Ok, so the generated assembly is indeed wrong, but it's different to the cross-compiled assembly. What happens is in the optimizer the compiler tries to determine the lowest possible precision of a floating point constant, and this seems to go badly wrong in this case, and the compiler figures it can do a single precision floating point load for a double precision inline constant. And the assembler complains about that. However, I verified on real hardware (68060), I cannot reproduce this at least with the 3.2.0 Amiga native compiler, neither for native Amiga code, nor when crossbuilding for Linux. Then the generated assembly is always correct. I also verified if the native compiler contains the correct code sequence (by disassembling its binary) for that opimization, and the answer is yes. I really need to put my real hardware Linux-m68k setup together again, to be 100% sure this is not an FPC issue, but at this point I think it isn't. What is the build host? QEMU? If yes, which version? I tested a slightly older QEMU (3.1, as bundled with Raspbian), and its floating point support seems quite badly broken. Even trivial code which uses the FPU seems to fail. Like, printing the value of "Pi" seems to show '4.0' ... :) Like it's permanently stuck in round up mode, but fiddling with FPCR values don't seem to change anything. Same code works on real hardware and in UAE. BTW, FPU problems didn't occur in Free Pascal 3.0.4 because that could not use FPU at all, so this is not a regression. FPU support was new in 3.2.0 for m68k. You can switch to software floating point support by passing OPT="-CfSOFT" argument to the Makefile (this was the default in 3.0.4 for m68k). But this shouldn't be the default in a 3.2.0 Debian package, but maybe worth a shot for a test. Cheers, -- Charlie
