I've just switched to ocaml 4.02, and it works only on carlit because
of GLIC 2.14 is not installed on other machine.

also, add some missing files.

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

I know they fail, but I'll fix that latter.

Also disable tests that involves ecxexe with files that contain 'merge'.
indeed the -ec backend is not the priority.

nb: bad timings is due to NFS and pavé that is dying.

to behave as scanf("%d")

(the function that perform this job is actually in rdbg-plugin so that it is shared
with lutin and rdbg)

The translation was faithfull to the comment, but the comment was wrong :
in order to translate a condact, we need clocks (when) !

node condact_toto(i0:bool; i1:int; i2:int) returns (o0:int) = Lustre::condact<<toto, 0>>;

is now translated into:

condact_toto(i0:bool; i1:int; i2:int) returns (o0:int)
let
  o0 = if i0 then current(toto(i1 when i0, i2 when i0) ) else (0 fby o0);
tel

is the clock of the quicker clock among its inputs, not among its output !

To acheive that, I gave a diffretent name to each created executable
(vs a.out) to avoids races.

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.

soc2c: fix the code generated for array concatenation (which was raising a warning and a Seg fault).

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, for big integers, looking at |x-x'|<eps leads to false
positive, because of the precision (*); it is better to to look at
|1-x/x'|<eps

(*) the precision (-p 6) influence the comparison, because the SUT
currently sends its result via a socket and truncate the result
(which is probably a bad idea).

nb : the exec time explose (x3), but for an external (unknown) reason
(undoing the change leads to the same exec time ~800s).

nb : the -exec mode was working because I did not use the generated soc,
which was completely wrong.

Note that to do that, I have modified the CURRENT variant of
Lic.val_exp, to attach it the clock the current holds on. Indeed, the
clock is mandatory to generated correct code...

In an ideal world, this clock information may have explicitely been
set by the user ("current(clk_of_X,X)" instead of "current(X)"), but
for historical reason, it is not the case.

Hence, this information is added as soon as it is available, namely,
during clock checking.

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

and -2c).  Indeed, the l2lExpandArrays sometime transforms a
Lic.var_exp ve into TUPLE[ve].

# of unexpected failures	101->109

but actually, some new test passes causes several other failing test
to be tried, so it is not really a regression.

Indeed, ite are polymorphic, and thus inventing names during soc
instanciation is error-prone, ugly, innefficient, and increase the
code size.

Moreover, using C ite to translate them online (ie, without going
trough a soc) is straigforward

# of unexpected failures	104->101.

In other words, consider ">" and co as overloaded operators, not polymorphic ones.

where I've removed the handling of polymorphism.

where I've removed the handling of polymorphism.

e.g., by replacing "plus" by "iplus" or "rplus"

Hence now the following is accepted :
   res = map<<+,  N>>(x, a, b);

but still not

  a_or_b = map<<Lustre::if,  N>>(x, a, b);

For instance,
  node toto = map<<Lustre::if,  N>>(x, a, b);
is rejected.

The problem with this change is that we now also reject equations such as
   res = map<<+,  N>>(x, a, b);

which could be avoided. Probably L2lRmPoly does its job partially.