Closed MohamedGhardallou closed 2 years ago
I confirm there is an output from an activity that should have been aborted in the tick where stop_btn
is true.
I'll have to investigate further why is this the case.
The minimal repro for this bug is
activity B ()
var x: int32 = 18
cobegin
cobegin
await true
x = -42
with
await true
end
with
await true
end
end
@[EntryPoint]
activity A ()
when true reset
run B()
end
end
Here x
should never become -42 but it does (and stays so forever after the first tick).
The reason is that we do initialise the main program counter of an activity but we leave all others unchanged and rely on control flow starting for the first statement to take care of the rest. This leaves the further nested ones in their old state from the previous invocation. None of our code generation tests seems to catch it.
Fix is on the way.
Hello @FriedrichGretz The fix is working thanks .
but I see that some counters are assigned twice . it should be optimized by the compiler but just in case you missed that .
Thanks
Yes, everything is zero-ed out and then the main program counter is set. Indeed this is a bit wasteful but I guess the C compiler will optimise it away.
Is the version bumped after the fixes? For me "blechc --version" still shows "Blech Compiler 0.7.0+0"
@mschlund now you can use the latest release v0.7.2 you will see
Blech Compiler 0.7.2+0 Copyright (C) 2019-2022 see blech-lang.org
Hello,
Describe the bug
please consider the following program :
env.h
Expected behaviour
If you execute this program for 2 second (2000 cycles) you should see the following output on the screen : log_int 0 log_int 10000 log_int 10002
After 2 seconds verify_basic activity is in state 2 (infinite loop). if we set stop_btn to true and we do one step log_int(2) is executed. This is a bug.