[sdcc-devel] [ sdcc-Bugs-861138 ] For loops broken

[SourceForge.net <no...@so...>]

Bugs item #861138, was opened at 2003-12-16 12:11
Message generated for change (Settings changed) made by epetrich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=861138&group_id=599

Category: None
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mattias Lindblad (matli)
Assigned to: Erik Petrich (epetrich)
Summary: For loops broken

Initial Comment:
The code generation for regular for-loops appears to be
broken.

A simple example of this behaviour is demonstrated by
the following function:

void test()
{
  unsigned char i, j;
  for (j = 0; j < 5 ; j++) {
    i = 1;
  }   
}

Command used for compiling it:
matli@sun73[/tmp] % sdcc -S ctest.c 

Version info:
matli@sun73[/tmp] % sdcc -v        
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.3.6 (Dec 16 2003) (UNIX) 
matli@sun73[/tmp] % 

(built from the 2003-12-13 source snapshot)

The test() function part of the .asm-file looks like
this:
;------------------------------------------------------------
;Allocation info for local variables in function 'test'
;------------------------------------------------------------
;------------------------------------------------------------
;ctest.c:1: void test()
;       -----------------------------------------
;        function test
;       -----------------------------------------
_test:
        ar2 = 0x02
        ar3 = 0x03
        ar4 = 0x04
        ar5 = 0x05
        ar6 = 0x06
        ar7 = 0x07
        ar0 = 0x00
        ar1 = 0x01
;ctest.c:4: for (j = 0; j < 5 ; j++) {
;     genAssign
        mov     r2,#0x00
00103$:
;ctest.c:5: i = 1;
;     genDjnz
;       Peephole 132    changed ljmp to sjmp
;       Peephole 205    optimized misc jump sequence
        djnz    r2,00103$
00108$:      
00109$:
;ctest.c:4: for (j = 0; j < 5 ; j++) {
00104$:
        ret


The problem is obviously that 0x00 is loaded into r2
instead of 0x05.

//Mattias Lindblad


----------------------------------------------------------------------

Comment By: Mattias Lindblad (matli)
Date: 2003-12-17 02:37

Message:
Logged In: YES 
user_id=500543

Ah, OK. No problem.

The fix seems to solve my problem (at least for my example,
I havent been able to try the new version on the real
project yet). Thanks!

----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2003-12-16 21:22

Message:
Logged In: YES 
user_id=635249

It's visible now. I'm sorry, I forgot about the lag between
the developer cvs and the public cvs. If everything is
working correctly, the public cvs should be no more than 5
hours out of sync with the development copy.


----------------------------------------------------------------------

Comment By: Mattias Lindblad (matli)
Date: 2003-12-16 17:44

Message:
Logged In: YES 
user_id=500543

Currently a 1.79 version of SDCCval.c doesn't seem to exist.
1.78 is the last that I can see (by a regular checkout or by
browsing the CVS tree).

However, one example of a system where this bug is present is:
 SunOS 5.9 Generic_112233-04 sun4u sparc SUNW,Ultra-4


----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2003-12-16 14:20

Message:
Logged In: YES 
user_id=635249

I believe that this is an endian problem while computing the
loop count constant. If so, it should be fixed by
src/SDCCval.c 1.79. However, the SourceForge compiler farm
is having some difficulties at the moment, so I can't verify
this myself.

If you can, update this file via cvs (or download a newer
snapshot, when available) and let us know if it is fixed.
Otherwise, specify your compute's OS & architecture and I
will look at this further when the compiler farm is running
again.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=861138&group_id=599