| Author |
Message |
pjc30943
Joined: 02 Dec 2005
|
|
Posted: 03 October 2008, 23:32 PM Post subject: If..Then error |
|
|
For the following example on a 1280n:
| Code: | 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:
| Quote: | 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:
| Quote: | 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: | 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 |
|
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 04 October 2008, 3:19 AM Post subject: Re: If..Then error |
|
|
| pjc30943 wrote: | | 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. |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
|
|
Posted: 04 October 2008, 16:21 PM Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 04 October 2008, 16:46 PM Post subject: |
|
|
| pjc30943 wrote: | | [I]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: | 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: | 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. |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
|
|
Posted: 05 October 2008, 1:21 AM Post subject: |
|
|
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. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 05 October 2008, 2:00 AM Post subject: |
|
|
| pjc30943 wrote: | | 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. |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
|
|
Posted: 07 October 2008, 1:27 AM Post subject: |
|
|
| dkinzer wrote: | | 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: | 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 |
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 07 October 2008, 2:35 AM Post subject: |
|
|
| pjc30943 wrote: | | 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. |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
|
|
Posted: 10 October 2008, 19:04 PM Post subject: |
|
|
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"! |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 10 October 2008, 20:13 PM Post subject: |
|
|
| pjc30943 wrote: | | 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. |
|
| Back to top |
|
|
|
