Also provide a default version of those macros using memcpy.

that expands the call of the specified node (can be used for several nodes).
Remove the previous --do_not-expand-nodes <string>

Also, the L2lExpandNodes pass now deletes the expanded nodes from the
current LicPrg.t.

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

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, 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

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

More precisely, it was always returning the default value when the
activation condition was false instead of returning "dft_val fby out".

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

nb: test run on trieves, not triglav that is down, so the time is meaningless

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

By redirecting the stderr of ecexe onto stdout, ecexe now terminate properly when called from lurette.

Hence, I have no more unresolved test (they are now failures) and the exec
time is now 98s (versus 217!!)

Some failures were actually due to wrong programs (mved to should_fail/semantics)

nb : the change has actually been done in lurette.

when the arity of an alias node was wrong.

itself calls another node on a non-trivial clock (i.e., using a when)
was not producing correct code.

I've fixed this by performing the fix-point on nodes rather than on
equations. Indeed its more natural and efficient, and it avoid the
problem above. However, I did not really fix the problem, but just
turn around it. All tests seems to work fine though.

nb : #FAILS=81->80 (and -2 unresolved, but because I fixed the prog)

 nb : #FAILS=84->81

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

(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.

Add --gen-autotest option that generates  a Lutin file and an oracle Lustre file suitable to compare the result of 2 Lustre compilers

nb : programs do run, but I did not check that they run correctly...

Also fix a regression introduced in the previous change where
incorrect ec code was generated for diese.

BTW, put everything that concerns node environement into the new
IdSolver module (from the Lic module).

Indeed, part of licDump was done in lic, but that part should
not depend in the compil option.

Pascal prepared « the field » for that change.

The only culprit was the one in unifyClock.ml::249, but
I've lazyfied most of the non-trivial verbose call.

The 2 remaining unresolved testq that were timeout-ing now pass in a few ms...

The whole non-reg test time has been divided by more than 2!

nb : do not work for lv4/ec mode

Also fix some bugs in DumpLic when printing condact in other modes.