[sdcc-devel] [ sdcc-Bugs-832664 ] missing type propagation to int

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

Bugs item #832664, was opened at 2003-10-29 22:02
Message generated for change (Comment added) made by bernhardheld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=832664&group_id=599

>Category: Icode generator
>Group: None
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Stas Sergeev (stsp)
Assigned to: Bernhard Held (bernhardheld)
>Summary: missing type propagation to int

Initial Comment:
Hi.

There seem to be a bug which causes a data loses during
the evaluation of some complex expressions.
The program that demonstrates the bug, is attached.
Also here it is:
---
#include <at89S8252.h>

int c;
unsigned char p;

int main()
{
  p = SBUF + 13;
  c = 2 | ((int)1 << p);
  return c;
}
---

The result is that c==2.
The asm code in question follows:
---
;shift.c:9: c = 2 | ((int)1 << p);
;     genLeftShift
	mov	b,_p
	inc	b
	mov	r2,#0x01
	mov	r3,#0x00
	sjmp	00104$
00103$:
	mov	a,r2
	add	a,acc
	mov	r2,a
	mov	a,r3
	rlc	a
	mov	r3,a
00104$:
	djnz	b,00103$
;     genCast
--> There might be no cast to byte <---
;     genOr
	orl	ar2,#0x02
;     genCast
	mov	_c,r2
	mov	(_c + 1),#0x00
--> so it was casted, the higher byte is lost <---
;shift.c:10: return c;
---

The strange thing here is that the expression
c = (1 << p);
gets evaluated correctly, but
c = (int)2 | (1 << p);
is not and only
c = (int)2 | ((int)1 << p);
is evaluated correctly.
What puzzles me is that adding "2 |" affects the
evaluation of (1 << p) making it to loose the higher
byte, while it seems logical to expect that these
expressions are independant.

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

>Comment By: Bernhard Held (bernhardheld)
Date: 2003-10-31 22:53

Message:
Logged In: YES 
user_id=203539

You're right, it's a bug. 
SDCC tries to use 8 bit values as far as possible. Therefore 
the constants 1 and 2 are "signed char". At least SDCC is 
doing the whole computation in 8 bit only (see the output with 
--dumptree). It would be easy to change everything to "int", 
SDCC would perfectly comply with the standard. But I'm sure, 
that dozens of users will complain the next day about the 
unacceptable increase of memory consumption ... 
 
The real bug is, that type flows only bottom up 
(decorateType()). A type propagation, which flows the other 
way round, is still missing. I've already faced the problem 2 
weeks ago, but there's still a far way to go. A lot of code will 
be necessary to handle many exceptions. 
 
I've re-opened your report to have a reminder for this special 
case. 

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

Comment By: Stas Sergeev (stsp)
Date: 2003-10-31 21:52

Message:
Logged In: YES 
user_id=501371

Thanks for the fix, although I think it is not complete, or
at least there is something fishy about it.
It fixes the original test-case, but if I change the line
c = 2 | ((int)1 << p);
to
c = 2 | (1 << p);
the result is that c==2 again. I think this is not correct.
Also considering that "c = 1 << p" gives the proper value,
not zero, I suspect the bug is still there.
Am I missing something?

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

Comment By: Bernhard Held (bernhardheld)
Date: 2003-10-31 16:46

Message:
Logged In: YES 
user_id=203539

Fixed in SDCCast.c 1.193

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

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