#660 For loops broken
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
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.
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
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.
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!