On Sunday, 20 November 2016 at 16:27:24 UTC, Stefan Koch wrote:
On Sunday, 20 November 2016 at 15:37:50 UTC, Stefan Koch wrote:Furthermore I need to extend my bc_tests. to make sure the interpretation is the same.Such that this bug cannot happen again.before. I have extended my test-suite to test this case.It is crucial that the c backend and the interpreter back-ends do always return the same correct value. As those are both testable at CTFE.I have plans to implement a small CTFEable instruction-set-simulator for the intel 486 processor. That way I can make sure that my x86-backend does what it is supposed to do.However this is further down the road :)
A bug in Do-While handling appeared that was hidden by the previously incorrect behavior.
When writing do { ... } while(true/false)
The IR generated would tell the interpreter to evaluate the
condition flag.
However the load of a constant does not modify the condition flag
and therefore if the loop is executed or not, depends on the
result of a previous comparison.
The fix is simple check for the (false/true) constants. (DMD has a shortcut for this, awkwardly named isBool() ) with an even more awkward usage.if (expression.isBool(true)) { // this expression is a constant which evaluates to true } else if (expression.isBool(false)) {// this expression is a constant false
else { // this value is not a constant }
