[sdcc-devel] [ sdcc-Bugs-810746 ] BadCode when --nogcse --nolabelopt

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

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

Category: Icode generator
Group: fixed
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stas Sergeev (stsp)
Assigned to: Erik Petrich (epetrich)
Summary: BadCode when --nogcse --nolabelopt

Initial Comment:
Hi.



I tried to compile a simple program without an

optimisation, and it seems that the

sdcc produces a bad code when the --nogcse and the

--nolabelopt options are used together.

I used to think that disabling optimisation improves

the reliability, but not any more :)



sdcc is from CVS,

sdcc -v

SDCC :

mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400

2.3.5 (Sep 18 2003) (UNIX)



The example program is attached.

Command line:

sdcc -mmcs51 --xram-size 0 --code-size 8192 --nogcse

--nolabelopt pluttmp.c



The bad code looks as follows:

---

;pluttmp.c:170: a=*(++p);

;     genPlus

;     genPlusIncr

	inc	r2

	cjne	r2,#0x00,00131$

	inc	r3

00131$:

00108$:

;pluttmp.c:155: for (a=*p;(a!=0x00)&&(pos<32);pos++){

---

That code obviously misses something. It is enough

only for ++p, but a=*() is omited.



The proper code (when the opt is not disabled), looks

as follows:

---

;pluttmp.c:170: a=*(++p);

;     genPlus

;     genPlusIncr

	inc	r2

	cjne	r2,#0x00,00132$

	inc	r3

00132$:

;     genPointerGet

;     genGenPointerGet

	mov	dpl,r2

	mov	dph,r3

	mov	b,r4

	lcall	__gptrget

	mov	r5,a

;pluttmp.c:155: for (a=*p;(a!=0x00)&&(pos<32);pos++){

---



Because the work-around exists, this problem is not

severe for me, but probably worth fixing anyway:)

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

>Comment By: Stas Sergeev (stsp)
Date: 2003-09-26 21:50

Message:
Logged In: YES 
user_id=501371

Thank you for the fix, seems to work.



> This was certainly educational.

Yes, but to be honest, within the whole week I was not

able to port any single small test program to sdcc.

They all are compiling but are not working properly.

I have tracked more bugs, which are not educational.

I am going to open the reports for them soon either

(sorry for making you busy, I was planning a quick

transition, but...)

Btw, what do you think, would it be reasonable to use

sdcc for the mission-critical software, where the

reliability is extremely important? Is it mature enough

for production? Oh well, back to work...



Thanks again for your help.

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

Comment By: Erik Petrich (epetrich)
Date: 2003-09-26 12:05

Message:
Logged In: YES 
user_id=635249

This was certainly educational. Fixed in src/SDCCdflow.c 1.10



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

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