Thanks for your help and suggestion. I forgot to mention that my program is parallel, using MPI. The problem could be possibly connected with some buffer overrun in MPI. I have three consecutive MPI_Reduce instructions on three medium sized vectors (108 elements). If I take out one of these reductions, everything seems to work well even with -O3. Otherwise, it always crashes (I retried many times) with both -O2 and -O3, but with -O it seems to work fine. The whole program is rather big, but maybe I can cut out some routine that reproduces the crash and post it. As for using gdb, I tried it, but it seems to give different results, because it's only able to run on one processor.

Thanks, regards

Silvio a Beccara

I retried to compile with different optimisation switches, and the results are as follows:

| (General question, general advice.) | | - If the "sometimes" is really meant so, i.e. doing the exact same | thing (e.g., compiling the same source and removing all .gpi files | before) crashes sometimes and not other times, it's quite likely a | hardware problem. PC hardware is known to often be buggy, | especially under heavy load, and compiling with `-O3' is known to | cause heavy load and to be quite sensitive to hardware problems. | In such cases, reducing the load (e.g., give the machine some | breaks), or better cooling, or even "downclocking" the processor | might help. See http://www.bitwizard.nl/sig11/. | | (My own machine does this sometimes as well, in particular when | compiling with `-O3' for a long time -- fortunately not very | often, except on hot summer days which is quite a clear indication | that it's a thermic problem ...) | | - Try to reproduce the crash in a small test and send it. If I can | reproduce the crash, I can most likely fix it. | | Running GPC with `--debug-source' will output the source it's | compiling so you see where in the code it crashes. | | - Try a newer GPC version. | | - Get a trace of the crash (enable core dumps, run the crashing | compiler again, call `gdb <path/to/gpc1> core' and enter `i s'). | With this output, I *might* be able to tell more. | | Frank

I've been trying to get up to tricks with the in clause of uses, eg.

uses GHJStdDefs in 'GHJLibraries/GHJStdDefs.p' ;

It seems to me that the in clause only supports filenames, not paths - true? (or put another way, that's what it appears to do: is this the intended/standard/expected behaviour?) The only way I have been able to get GPC to see my libraries is to use --unit-path on the command-line. I'll pop a note into the doc forms later.

The reason I wanted to do the above was so I could place a soft link to the real library (etc.) directory in the working code directory, so that the library locations are effectively embedded in the code, yet are relative to the directory they are compiled from. Also, it means I can later point the link to new versions of the library and just recompile without altering anything else.

(Yes, I know I should really use make files...)

Grant