Indeed, the shift from pave to bauges changes its behavior.

generation has been stopped in the middle of the process because of
an error in order to avoid to run test that will fail for sure.

Also remove the port number from the sum files

by taking advantage of the multi-proc -> x5 speedup with j 4 !

Note that i do not use -j 4 (qtest) for reference (reftest) to lower
timings distorsion due to the machine load.

Indeed, starting from a clean /tmp dir changed the result of the non reg test...

Indeed, once the activation condition has been true, and when it is
false it wax returning the default value instead of the previous one.

# of expected passes 		1512 -> 1519
# of unexpected failures	84 -> 78

For instance, do not launch tests that perform result comparison (via
lurette) on files that contains extern nodes (as they cannot be
executed) or package.  Package do not work because appending the
tested lustre file with the generated oracle as I do is wrong in
presence of package.

Moreover, my current test process is not able to test programs which
main node IOs are not all on the base clock. I have fixed this by
patching the examples.

# of expected passes 		1508 -> 1512
# of unexpected failures	130 -> 84

30 tests fail, but 169 pass!!!

# of expected passes 		1339 -> 1508
# of unexpected failures	100 -> 130

of expected passes		1073 -> 1116
of unexpected failures	325 -> 282

46 ok, 159 ko...

121 ok, 110 ko. Basically, ko programs contains arrays arrays and
structures.

That was quite confusing for rdbg -lurette --*-stdio !!!

nb : I've finaly understood the performance/out of memory problems I
had for that last 6 months !!!!! It was due to the lurette.cov file
that was getting larger and larger.

A few Array.copy were necessary when updating the memory.

Also, check programs that should fail using lurette instead of just
lus2lic. Indeed, some programs are only suposed to fail at runtime.

Change the main node names of prog in should_fail as it is necessary
for Lurette non-reg scheme

Indeed, I've intentionally removed the when statements in clocked local var like this :

 var
    v:int;

because the following was producing a syntax error in ecexe:

 var
    v:int when c;

But Actually, the right thing to do was to generate the following:

 var
    (v:int) when c;

...

nb : #FAILS=90->89

112 tests failed, and 127 passed !!

nb : I've transformed all the regressions I've seen into todo entries
in todo.org.

nb 2 : I did not mv the newly broken tests into the broken dirs. I'll
do that for those I do not want to fix in the short term.