Hello!

First I wrote about this issue to Florian Klampfl, but looks like he is on vacation or something like that - there have been no messages from him in mailing list for about a week. So I am repeating, now with mailing list.

I am author of the ALGLIB - open source numerical analysis library. ALGLIB contains C++, C#, VB6 and Delphi code (same functionality in different languages). ALGLIB 2.1.2 is tested under Win32 compilers only, but next release will be tested under wide set of Windows and Linux compilers (both x86 and x86_64).

Since Delphi is Windows-only and have no free command line compiler, I want to make transition to the FreePascal compiler. Targeting free cross-platform compiler seems better alternative than targeting proprietary x86+Windows only compiler without even free command-line toolset.

I've planned to announce full FPC compatibility in ALGLIB 2.2.0 However, I have problems with x86_64 FreePascal for Linux (bug #15206, http://mantis.freepascal.org/view.php?id=15206 - compiler crashes when trying to compile ALGLIB).

May I ask when are you going to make next FPC release and will bug #15206 be fixed in that release? Currently it is the only thing that stops me from declaring full FreePascal compatibility for upcoming ALGLIB 2.2.0

Another question: are you interesting in using ALGLIB as a part of the FPC test suite? Large numerical analysis libraries are good in triggering compiler bugs (for example, GMP and MPFR have discovered many bugs in GCC).

I can help you with testing new FPC releases on x86/x86_64 platforms, if you want.

Sergey Bochkanov.

The next release will be out during one of the coming weeks, and is currently at RC1 status. This means that only regressions are still possible candidates for inclusion in the final release. Since your bug 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.

Another question: are you interesting in using ALGLIB as a part of the FPC test suite? Large numerical analysis libraries are good in triggering compiler bugs (for example, GMP and MPFR have discovered many bugs in GCC).

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.

Jonas

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).

Everything compiles fine here on Linux/i386 and Linux/x86_64, although with 2.5.1 (I don't have a 2.4.0 available right now for those platforms, but on the other hand I can't think of any changes since 2.4.0 was branched off that could influence this). It also compiles fine on Mac OS X/ppc with 2.4.0rc1.

You may want to compile the compiler with debug info: download the sources, go into the fpc directory and type
make OPT="-O- -gl" all

Afterwards use resulting compiler/ppcx64 to compile the program (you don't have to install it or so, since you already have the 2.4.0rc1 units installed). You should now get file names and line numbers next to the backtrace when the compiler crashes.

Our tests are very simple:
a) their file names have to start with "t" and the extension has to be ".pp"
b) if they require special command line options, they have to be mentioned in the first line of the test program file like this: { %opt=-Mdelphi -Si }
c) the test programs have to exit with exit code 0 if they were successful, and with a non-zero exit code otherwise

The tests are automatically compiled and run by a Makefile (which compiles/runs all files in our test directories conforming to the pattern mentioned a) above)

Jonas

Hello,

Everything compiles fine here on Linux/i386 and Linux/x86_64, although with 2.5.1 (I don't have a 2.4.0 available right now for those

Not sure whether bug was fixed or just made less apparent.

You may want to compile the compiler with debug info: download the sources, go into the fpc directory and type make OPT="-O- -gl" all

I'll try to do it and write about results.

Very simple and pretty compatible with my framework. However, I have several questions:
0. What about newlines? Unix, Windows, does not matters?
1. Can test files reference another units? Typical test consists of starter program, which prepares environment and calls unit test (separate unit), which uses unit being tested (separate unit), which uses several supplementary units.
2. Where should I place these "another units" and how should I reference them?
3. I want to test package under different compiler optimizations ("/O1", "/Os", ...) Should I include different combinations of parameters into my set of tests - i.e. write test1_o1.pp, test1_o2.pp, test1_os.pp? Or I have to leave such things for Makefile?

Sergey Bochkanov wrote

Very simple and pretty compatible with my framework. However, I have several questions: 0. What about newlines? Unix, Windows, does not matters?

Does not matter, handled by svn (and even if not, by FPC).

Units can be placed in the same directory as the test program. You can just add the to the uses clause of your program. The name doesn't matter (other than that it shouldn't start with a "t"), but by convention they start with "u" for our tests. Note that we generally don't create separate subdirectories for our tests, they're all located in only a few, large directories. See http://svn.freepascal.org/svn/fpc/trunk/tests/ . We could add an extra alglib directory there in which all of your tests are placed.

3. I want to test package under different compiler optimizations ("/O1", "/Os", ...) Should I include different combinations of parameters into my set of tests - i.e. write test1_o1.pp, test1_o2.pp, t

No, the entire testsuite itself is tested using different parameters. See http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi

Jonas

Hello,

You may want to compile the compiler with debug info: download the sources, go into the fpc directory and type make OPT="-O- -gl" all

Results so far - crash when testing mlpe.pas unit:

Last line seems to be corrupted (compiler warning mixed with line numbers), its correct form should be:

$000000000056CB5B line 1531 of fppu.pas

FPC 2.4.0rc1 was used (built from source with options you've specified). Random nature of this bug is confirmed - it appears with probability 20-40%.

Steps to reproduce it:
1. download http://www.alglib.net/share/fpc-crash.zip
2. unpack somewhere (looks like that place does not matters)
3. cd into the "fpc-O-" directory
4. edit "check" script. It assumes that FPC compiler is located in /ALGLIB/fpc_src/fpc-2.4.0rc1/compiler/ppcx64, point it to your installation.
5. Set +x permissions for "check" and "cyc" scripts
6. execute "cyc" script. This script will try to call "check fpc mlpe -O-" several times until crash occurs. After 1-2 passes it occurs, script terminates. You can find compiler log in log.txt

If you find it difficult to reproduce on your system, I may try to find another example (it is only one unit, but there are several units which sometimes crash when compiling)

Our tests are very simple: a) their file names have to start with "t" and the extension has to be ".pp"

I think that I'll write small script which renames ALGLIB units according to your conventions. They have very regular structure (because they are automatically generated) so simple regexp will do the work.

One more question - ALGLIB takes about 3-6 minutes to make one pass through full set of tests. Is it fast enough for your framework?

Sergey Bochkanov.