If..Then error

[pjc30943]

For the following example on a 1280n:

Code: Select all

Sub Main()
	dim A as single, B as single, error as byte
	error = TestFunction(0, A, B)
End Sub

public function TestFunction(byval mode as byte, byref Var1 as single, byref Var2 as single) as byte
	
	debug.print "mode @ start="; mode
	if mode = 0 then
		debug.print "mode in case 0="; mode
		debug.print "Correct Result"
	else
		'debug.print "modeElse="; mode
	end if
	debug.print "mode @ end ="; mode
	TestFunction= 1
end function

If the "Else" statement is commented out as shown in the example--or if the Else case doesn't exist--the branching is incorrect depsite Mode being correct:

ZBasic v2.6
mode @ start=0
mode @ end =0

Note that "Correct Result" is not printed out.

If the debug statement in the "Else" case is uncommented, the result is correct:

ZBasic v2.6
mode @ start=0
mode in case 0=0
Correct Result
mode @ end =0

This is very unusual, as I don't quite see how the "Else" case influences branching...


=================================
EDIT: A more simple example is shown below.
If the Else is in the If..Then statement, there is no entrance into any of the If branches, and nothing is printed out between the first and last coded debug statements.
If the Else and associated statements are removed, then "Correct Result" is printed out as it should be.

Code: Select all

Sub Main()
	dim var1 as byte = 1
	
	debug.print "var1 @ start="; var1
	
	if var1 = 1  then
		debug.print "var1 in case 1"; var1
		debug.print "Correct Result"
	else
		debug.print "var1 in case else="; var1
		debug.print "Incorrect Result"
	end if

	
	debug.print "mode @ end ="; var1
end sub

[dkinzer]

I don't quite see how the "Else" case influences branching...

It's simply a case of an optimization error. The Else clause can obviously be removed since it is empty. The code in the compiler was incorrectly removing the If part, too.

The full story is actually more complicated when you take into account multiple ElseIf clauses and conditional expressions with side effects but I think that we have it working correctly now. We'll need to expand the test suite with more unusual cases to check for such situations.

[pjc30943]

Thanks Don. For the cases you mentioned--not necessarily just the one in the original post, but perhaps others I'm not aware of but could be in my code--is there a workaround?

[dkinzer]

s there a workaround?

The problem arises when the compiler sees no statements in an Else or ElseIf clause. I believe that you can avoid the problem by commenting out the entire Else or ElseIf as opposed to just the statements within it.

Code: Select all

   if mode = 0 then
      debug.print "mode in case 0="; mode
      debug.print "Correct Result"
'   else
'      debug.print "modeElse="; mode
   end if

Another way to get the same effect is this:

Code: Select all

   if mode = 0 then
      debug.print "mode in case 0="; mode
      debug.print "Correct Result"
#if 0
   else
      debug.print "modeElse="; mode
#endif
   end if

Lastly, you can avoid the problem by turning off optimization. This is accomplished by placing the option --optimize=no-optimize in your .pjt file. Doing so will have less impact on program size for native mode devices since the back-end compiler will still perform optimization. You should note, however, that unused public procedures will be included in the final code with optimization turned off in this manner.

[pjc30943]

Okay, thanks Don. For now I'll turn off optimization.
Note that I still had problems even when no Else was included: while testing, I seem to recall a situation where there was no Else case, only ElseIfs, and the error still manifested where the If would not be evaluated.

[dkinzer]

Note that I still had problems even when no Else was included.

If so, I'd like to see the specific case. I didn't see that with the test case that you gave in your original post.

[pjc30943]

If so, I'd like to see the specific case. I didn't see that with the test case that you gave in your original post.

The following exhibits the same issue as above, with the minor change of "ElseIf ... Then" instead of "Else":

Code: Select all

Sub Main() 
   dim var1 as byte = 1 
    
   debug.print "var1 @ start="; var1 
    
   if var1 = 1  then 
      debug.print "var1 in case 1"; var1 
      debug.print "Correct Result" 
   elseif var1 = 0 then
      debug.print "var1 in case elseif="; var1 
      debug.print "Incorrect Result" 
   end if 

    
   debug.print "mode @ end ="; var1 
end sub

[dkinzer]

The following exhibits the same issue as above, with the minor change of "ElseIf ... Then" instead of "Else"

OK, thanks. That's essentially the same issue because the compiler sees that the statements inside the ElseIf can never be executed and marks that clause as "not useful". This leads it to erroneously also mark the If clause as "not useful" resulting in the symptoms that you've observed. The version of the compiler currently being tested produces the correct code in this case as well.

[pjc30943]

Just a heads up in case anyone else encounters the same issues:
Turns out the current application no longer functions when compiling without optimization, which is required to remove the error discussed in this thread.
Most likely I had some functions that were verified as having worked back when this bug was active but unknown, and due to coding errors on my part, happened to work when certain cases were "optimized out"!

[dkinzer]

the current application no longer functions when compiling without optimization, which is required to remove the error discussed in this thread.

With --optimize=no-optimize, all optimization is disabled. You might try narrowing the scope of the disabled optimization. I believe that using just --optimize=no-unreachable-code will sidestep the original problem without disabling all optimization. Another optimization flag that may be useful is --optimize=no-useless-code.