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.

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.

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.

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.
>>>

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.
>>>>

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

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
---                                                                      ---

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

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