More precisely, issuing an "exit 2" is not enough for the
should_work proc in test/site.exp to state that the test fails.

That fix revealed a certain number of bad programs.
Some were not really wrong ; there were just not respecting the
naming convention used to automated the test (i.e., main node name =
file name).

It also releaved a real bug due to the fact that type
instanciatiation is not propagated during model instanciatiation,
where creates a loop between (Lic2soc.process_node and
Lic2soc.soc_of_node). Indeed it searches in the soc the table for an
abstract profile.

+ the utils/lustrequiv script that tries to state that 2 nodes a equivalent or not
using lesar and lurette.

Add an option --to-c-dont-inline-predef to get the previous behavior.

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.

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

Add the modes3x2 exemple of Pascal (its version + a la V6 version).

Fix the doc wrt the merge exemple (the tex was refering to a
non-existant file).

Work in progress...

(cf 55d3d77c470f416befd16a1b7d47f751eb2171fc)

Some generated intermediary variables where declared as int instead
of bool.  Funnily, ecexe was ok with that...

Also add support to rdbg to perform nonreg test. I do not plug yet it
as it's twice slower. but most of it seems due patch_ecexe. Indeed,
lus2lic -interface compile the whole program just to print the node
interface.

nb: it has detected a couple of existing bugs.

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

  #fail: 83 -> 81

The rationale is to avoid local vars blow-up on some
examples. Indeed, the generated oracle blows-up (e.g., on left.lus)
if we execute it via v4, whereas via v6 it works fine.

This change triggers a couple of bugs that ware easy to fix
(confusion between div and slash) that I've fixed along the way.
For the others, I'll see later.

Overall it's a progress albeit
  #fail: 80 -> 83

indeed:
  #unresolved: 20 -> 12
  #passes		878 -> 883
  time: 335 -> 228

The test now runs in 150s (versus 417s)

[...] for some reasons, i cannot reproduce the 150s !!!

where equations such as " ok = (x=x_ref); " are translated into incorrect v' lustre
when x is a structure or an array.

nb : #FAILS=152->135

(to be kind with data plotters).

Actually it does not fix any test, but I feel it is a (slight)
progress, so I commit it... Well, to be fair, one objective progress
is that I can now compile the test suite with the -np option.

(1) equations such as
 (x,y,z)=[0,0,0];
were generated with -en unless -ec was specified.

I've fixed that by always breaking tuples, even when global_opt.ec
is false (this condition was strange anyway).

(2) During node expansion, I create a fresh variable for each local
var in the expanded node, but old var names were still appering in
clock expression

indeed, consider that example :
var
  c:bool;
  x when c :bool;

I was generating something equivalent to

var
  c_fresh:bool;
  x_fresh when c :bool;

bou... Of course, it was working because in -ec mode, I need to
remove clock annotation when declaring local variables, which was
hidding the problem.

nb : because I've change test_lus2lic_no_node to use -lv4 instead of
-ec to generate the lustre oracle, which exposes new pbs (cf above).

(3) When expanding a node on the base clock with arguments on another
clock, I was not propagating that information (let's keep the
finger-crossed and hope the current fix is complete).

nb : the number of failing test cases is the same (5 new pass, but 5
new fail!!), but it actually is a progression. Indeed, the new test
failures ares due to the fact that this current change fixes a
problem that expose yet another one!

Actually, the newly exposed bug is not in the compliler, but in the
oracle I generate via the --auto-test option ; indeed, for testing
nodes which not all interface variables are one the base clock, I
should generate oracle that do take them into account.

112 tests failed, and 127 passed !!

- src + utils + tests au meme niveau
- tout ce qui est provisoire dans obj