Yes. The oldest compiler we use to compile is gcc 4.4. GCC 4.1 is from 2006,

Thanks. I managed to compile OM with GCC 4.4.7, but it seg faults on some models. The first time I tried it, it crashed in the omc_BackendEquation_traverseBackendDAEExpsEqn function. When I reverted to an SVN revision that works well on my first machine (r20338), it crashed somewhere else: omc_Tearing_traverseComponents.

Is this likely to be caused by the compiler version? If so, which version would you recommend?

Did you mix compiler versions without make clean in-between? Or did you perhaps run out of memory? Is this a 32-bit or 64-bit system? What model are you simulating? Big/small?

gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-8ubuntu1) works fine for us.

No, I copied a clean SVN checkout. It's a 64-bit Xeon cluster node with 8GB RAM. The model used is Wire.mo from Jens Frenkel, with N=2000 (this model takes 52 minutes to complete on my desktop machine).

This model and larger variants, up to N=9000, work on my desktop machine. My desktop is also 64-bit, and has 16GB of RAM, but I've often run two or three of these models in parallel without trouble.

I'm now trying the same GCC version as used on my desktop, 4.6.3. This necessitates an upgrade of the MPC library, so maybe this will help.

Did you use good optimization flags (same as the desktop)? The simulation could crash in these functions if you trigger a stack overflow (which is likely if no variables were optimized away from the stack). Are you using omc-bootstrapped on both machines or omc-rml on one of them?

Oh, and if it is a stack overflow, post the whole trace, like:

[bt] #4            /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_BackendEquation_traverseBackendDAEExpsEqn+0xc8d) [0x7f251358124d]

[bt] #5            /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_SynchronousFeatures_getVariableLists2+0x17d9) [0x7f25133f92e9]

[bt] #6..15868     /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_SynchronousFeatures_getVariableLists2+0x180c) [0x7f25133f931c]

The function with over 15000 iterations would be the culprit, not the functions higher up.

Cluster: OpenModelica Compiler 1.9.1+dev (r20338) (Bootstrapping version)
Desktop: OpenModelica Compiler 1.9.1+dev (r20338) (RML version)

I've now rebuilt the cluster's omc as an RML version, and this model completes successfully. Thanks for the tip. Do you happen to have a link to where I can learn about the differences between these versions?

Should I post more details about the crash with the bootstrap version, or is this an expected limitation of this version?

I already did fix some issues in the bootstrapped version. It works for n=2000 now. n=9000 causes the garbage collector to abort due to trying to allocate a too large block.
The RML version will be discontinued after the next release though. One of the changes in that version is that it uses the regular C stack for local frames. The RML version manages local frames explicitly on the heap. So the implementation is quite different; but it is possible to use "ulimit -s 16384" or even higher in the bootstrapped compiler if you need more stack space.
Another difference is that if you compile the bootstrapped version without optimizations (-O0), for example for debugging... You will get a different limit for recursive function calls since each stack frame will use more memory

Anyway, if you find more functions that are not tail recursive and trigger stack overflows, post them at https://trac.openmodelica.org/OpenModelica/newticket. Many of them are easy to fix.