Hello,
> occurs with FPC 2.2.4, that is not the case... On the other hand, have > you tried compiling it with FPC 2.4.0rc1? Maybe the bug is already > fixed. Yes, I've tried it with 2.4.0.rc1 (see additional note in bugtracker) - it is still there :( Tomorrow I'll try with 2.4.0.rc1 under Win64 - to see whether it is specific for Linix + x86_64 , or appears in x86_64 on any platform. Looks like that this bug is non-deterministic (see notes in bugtracker). It depends on presence of files not actually used/compiled, and it sometimes disappear for unknown reasons. I may send you VirtualBox image of Ubuntu-64 (I am running Linux under VirtualBox) if you have difficulties reproducing this bug. > If it doesn't have any external dependencies and preferably is cross > platform (endian safe, no reliance on 80 bit floating point precision > nor on intermediate calculations being performed using 80 bit > precision), I think that could indeed be a good addition. Well, it is aimed to be cross-platform: 1. no external dependencies 2. no explicit reliance on internal 80-bit floating point registers 3. should work with any kind of endianness However, I should say that (3) wasn't tested because I have only x86_64 hardware at my hands. And real testing with FPC is just in the beginning - it is the first week I've decided to switch to FPC and to abandon Delphi. So there are two units which still fail tests (may be, tolerances are too stringent... I am still investigating it). May be we should try with a small subset of the most stable units? I can generate build/check scripts for these units and you can try integrating it into your unit-testing framework. It should be easy to integrate - it is just a Bash script which subsequently compiles/runs unit tests (if you use another scripting tool, I may rewrite scripts). -- With best regards, Sergey mailto:[email protected] _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
