[Pkg-pascal-devel] Debugging FPC build issue on m68k

Karoly Balogh (Charlie/SGR) charlie at scenergy.dfmk.hu
Fri Aug 21 04:22:08 BST 2020


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



More information about the Pkg-pascal-devel mailing list