Author | Topic: DO CASE & IF bug | |
---|---|---|
mirda | DO CASE & IF bug on Thu, 01 Oct 2009 16:24:29 +0200 Hi everybody! Recently I discovered a bug (I think a optimisation bug) in DO CASE & IF statement. If you look at the following code, the result should be: 1 1 But, surprise, result is: 6 6 Code is: i = 1 DO CASE CASE i == 1 ? 1 CASE i == 2 ? 2 CASE i == 3 ? 3 CASE i == 4 ? 4 CASE i == 5 ? 5 CASE i == 1 ? 6 && program never should execute this command && because of first CASE ENDCASE IF i == 1 ? 1 ELSEIF i == 2 ? 2 ELSEIF i == 3 ? 3 ELSEIF i == 4 ? 4 ELSEIF i == 5 ? 5 ELSEIF i == 1 ? 6 && program never should execute this command && because of first IF ENDIF RETURN I use SL1 v1.9.355 "without" Visual Style and I've not tried this code with earlier versions of Xbase++. If I compile this code with debug (/b) option result is OK, but without debug flag result is wrong. | |
Joe Carrick | Re: DO CASE & IF bug on Thu, 01 Oct 2009 09:16:55 -0700 Try it using i := 1 mirda wrote: > Hi everybody! > > Recently I discovered a bug (I think a optimisation bug) in DO CASE & IF > statement. If you look at the following code, the result should be: > > 1 > 1 > > But, surprise, result is: > 6 > 6 > > Code is: > > > i = 1 > > DO CASE > CASE i == 1 > ? 1 > CASE i == 2 > ? 2 > CASE i == 3 > ? 3 > CASE i == 4 > ? 4 > CASE i == 5 > ? 5 > CASE i == 1 > ? 6 && program never should execute this command > && because of first CASE > ENDCASE > > IF i == 1 > ? 1 > ELSEIF i == 2 > ? 2 > ELSEIF i == 3 > ? 3 > ELSEIF i == 4 > ? 4 > ELSEIF i == 5 > ? 5 > ELSEIF i == 1 > ? 6 && program never should execute this command > && because of first IF > ENDIF > > RETURN > > > > I use SL1 v1.9.355 "without" Visual Style and I've not tried this code with > earlier versions of Xbase++. If I compile this code with debug (/b) option > result is OK, but without debug flag result is wrong. | |
mirda | Re: DO CASE & IF bug on Thu, 01 Oct 2009 20:05:02 +0200 It's the same, I tried it. On Thu, 01 Oct 2009 09:16:55 -0700, Joe Carrick wrote: > Try it using > > i := 1 > > mirda wrote: >> Hi everybody! >> >> Recently I discovered a bug (I think a optimisation bug) in DO CASE & IF >> statement. If you look at the following code, the result should be: >> >> 1 >> 1 >> >> But, surprise, result is: >> 6 >> 6 >> >> Code is: >> >> >> i = 1 >> >> DO CASE >> CASE i == 1 >> ? 1 >> CASE i == 2 >> ? 2 >> CASE i == 3 >> ? 3 >> CASE i == 4 >> ? 4 >> CASE i == 5 >> ? 5 >> CASE i == 1 >> ? 6 && program never should execute this command >> && because of first CASE >> ENDCASE >> >> IF i == 1 >> ? 1 >> ELSEIF i == 2 >> ? 2 >> ELSEIF i == 3 >> ? 3 >> ELSEIF i == 4 >> ? 4 >> ELSEIF i == 5 >> ? 5 >> ELSEIF i == 1 >> ? 6 && program never should execute this command >> && because of first IF >> ENDIF >> >> RETURN >> >> >> >> I use SL1 v1.9.355 "without" Visual Style and I've not tried this code with >> earlier versions of Xbase++. If I compile this code with debug (/b) option >> result is OK, but without debug flag result is wrong. | |
Joe Carrick | Re: DO CASE & IF bug on Thu, 01 Oct 2009 21:04:20 -0700 Very interesting because they both work perfectly for me. What OS and what version of Xbase++ are you using? mirda wrote: > It's the same, I tried it. > > > On Thu, 01 Oct 2009 09:16:55 -0700, Joe Carrick wrote: > > >> Try it using >> >> i := 1 >> >> mirda wrote: >> >>> Hi everybody! >>> >>> Recently I discovered a bug (I think a optimisation bug) in DO CASE & IF >>> statement. If you look at the following code, the result should be: >>> >>> 1 >>> 1 >>> >>> But, surprise, result is: >>> 6 >>> 6 >>> >>> Code is: >>> >>> >>> i = 1 >>> >>> DO CASE >>> CASE i == 1 >>> ? 1 >>> CASE i == 2 >>> ? 2 >>> CASE i == 3 >>> ? 3 >>> CASE i == 4 >>> ? 4 >>> CASE i == 5 >>> ? 5 >>> CASE i == 1 >>> ? 6 && program never should execute this command >>> && because of first CASE >>> ENDCASE >>> >>> IF i == 1 >>> ? 1 >>> ELSEIF i == 2 >>> ? 2 >>> ELSEIF i == 3 >>> ? 3 >>> ELSEIF i == 4 >>> ? 4 >>> ELSEIF i == 5 >>> ? 5 >>> ELSEIF i == 1 >>> ? 6 && program never should execute this command >>> && because of first IF >>> ENDIF >>> >>> RETURN >>> >>> >>> >>> I use SL1 v1.9.355 "without" Visual Style and I've not tried this code with >>> earlier versions of Xbase++. If I compile this code with debug (/b) option >>> result is OK, but without debug flag result is wrong. >>> | |
mirda | Re: DO CASE & IF bug on Wed, 07 Oct 2009 18:54:28 +0200 I use SL1 v1.9.355 "without" Visual Style on Win XP On Thu, 01 Oct 2009 21:04:20 -0700, Joe Carrick wrote: > Very interesting because they both work perfectly for me. What OS and > what version of Xbase++ are you using? > > mirda wrote: >> It's the same, I tried it. >> >> >> On Thu, 01 Oct 2009 09:16:55 -0700, Joe Carrick wrote: >> >> >>> Try it using >>> >>> i := 1 >>> >>> mirda wrote: >>> >>>> Hi everybody! >>>> >>>> Recently I discovered a bug (I think a optimisation bug) in DO CASE & IF >>>> statement. If you look at the following code, the result should be: >>>> >>>> 1 >>>> 1 >>>> >>>> But, surprise, result is: >>>> 6 >>>> 6 >>>> >>>> Code is: >>>> >>>> >>>> i = 1 >>>> >>>> DO CASE >>>> CASE i == 1 >>>> ? 1 >>>> CASE i == 2 >>>> ? 2 >>>> CASE i == 3 >>>> ? 3 >>>> CASE i == 4 >>>> ? 4 >>>> CASE i == 5 >>>> ? 5 >>>> CASE i == 1 >>>> ? 6 && program never should execute this command >>>> && because of first CASE >>>> ENDCASE >>>> >>>> IF i == 1 >>>> ? 1 >>>> ELSEIF i == 2 >>>> ? 2 >>>> ELSEIF i == 3 >>>> ? 3 >>>> ELSEIF i == 4 >>>> ? 4 >>>> ELSEIF i == 5 >>>> ? 5 >>>> ELSEIF i == 1 >>>> ? 6 && program never should execute this command >>>> && because of first IF >>>> ENDIF >>>> >>>> RETURN >>>> >>>> >>>> >>>> I use SL1 v1.9.355 "without" Visual Style and I've not tried this code with >>>> earlier versions of Xbase++. If I compile this code with debug (/b) option >>>> result is OK, but without debug flag result is wrong. >>>> | |
Rodd Graham | Re: DO CASE & IF bug on Fri, 02 Oct 2009 04:40:47 +0000 Hello mirda, I concur that this is an optimizer bug that should be reported to Alaska Software. I tested with 1.90.331 and am able to duplicate your results. My guess is that they are detecting the branch dependency upon a simple control variable and building a jump table lookup vs evaluating each conditional expression. However, the jump table optimization is not detecting duplicated values and overwriting the jump table with the last value found in the source. The fix is to prevent overwriting populated targets of the jump table effectively eliminating the later duplicate dead code. I was able to prevent the optimization by introducing dead code (that should have been optimized out) to prevent matching the jumptable optimization. The extra code is below merged into your example. > i = 1 > DO CASE CASE .f. ? 0 > CASE i == 1 > ? 1 > CASE i == 2 > ? 2 > CASE i == 3 > ? 3 > CASE i == 4 > ? 4 > CASE i == 5 > ? 5 > CASE i == 1 > ? 6 && program never should execute this command > && because of first CASE > ENDCASE IF .f. ? 0 > ELSEIF i == 1 > ? 1 > ELSEIF i == 2 > ? 2 > ELSEIF i == 3 > ? 3 > ELSEIF i == 4 > ? 4 > ELSEIF i == 5 > ? 5 > ELSEIF i == 1 > ? 6 && program never should execute this command > && because of first IF > ENDIF > RETURN > Regards, Rodd Graham, Consultant Graham Automation Systems, LLC | |
Andreas Gehrs-Pahl | Re: DO CASE & IF bug on Fri, 02 Oct 2009 13:12:17 -0400 Mirda, Rodd, >I concur that this is an optimizer bug that should be reported to Alaska >Software. I tested with 1.90.331 and am able to duplicate your results. It actually happens with all Xbase++ versions, at least as far back as 1.20.178 (from 1998). >I was able to prevent the optimization by introducing dead code (that >should have been optimized out) to prevent matching the jumptable >optimization. The problem is quite specific and only happens if ALL your case or if/ elseif constructs ONLY compare the SAME variable with a single CONSTANT. It won't happen if any of the case or if/elseif conditions is not using that variable or comparing that same variable to a non-constant, like another variable or an expression that needs to be evaluated at runtime. Expressions that are also "constant" (like "1 + 0") are also optimized away, and won't help. But using Rodd's workaround should always work, as the branch will never be executed, but the compiler will not optimize the code into some sort of hash table, as the "i" variable isn't used anywhere. Actually adding that "case .f." at the end will even remove the (extremely small) speed penalty of an additional comparison. Adding a final "otherwise" or "else" will not have any effect, though. What I don't like is the fact that including debug info will alter the outcome -- making it much more difficult to find the problem during application development. -- Andreas --- --- Andreas Gehrs-Pahl E-Mail: GPahl@CharterMI.net 415 Gute Street or: Andreas@DDPSoftware.com Owosso, MI 48867-4410 or: Andreas_Gehrs-Pahl@CrimeCog.com Tel: (989) 723-9927 Web Site: http://www.Aerospace-History.net --- --- | |
Rodd Graham | Re: DO CASE & IF bug on Fri, 02 Oct 2009 20:33:10 +0000 Hello Andreas Gehrs-Pahl, > What I don't like is the fact that including debug info will alter the > outcome -- making it much more difficult to find the problem during > application development. This is likely because the debugger needs the object code to directly correspond with the source code which turns off the optimization. Regards, Rodd Graham, Consultant Graham Automation Systems, LLC | |
mirda | Re: DO CASE & IF bug on Wed, 07 Oct 2009 18:56:45 +0200 Thanks Rodd & Andreas I'll send mail to Alaska mirda On Fri, 02 Oct 2009 20:33:10 +0000, Rodd Graham wrote: > Hello Andreas Gehrs-Pahl, > >> What I don't like is the fact that including debug info will alter the >> outcome -- making it much more difficult to find the problem during >> application development. > > This is likely because the debugger needs the object code to directly correspond > with the source code which turns off the optimization. > > Regards, > > Rodd Graham, Consultant > Graham Automation Systems, LLC |