From: SourceForge.net <no...@so...> - 2003-11-21 05:27:59
|
Bugs item #838241, was opened at 2003-11-07 17:47 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=838241&group_id=599 Category: C-Front End Group: fixed Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stas Sergeev (stsp) Assigned to: Erik Petrich (epetrich) Summary: No checks for matching of prototype and definition Initial Comment: Hi. SDCC doesn't seem to check whether the variable is declared similarly to how it is defined. This leads to a bad code and sometimes it is difficult to find the problem. For example the following code produces no errors during compile: --- extern data char a; idata char a; --- Now "a" is declared to be in data but defined to be in idata. If the declaration is in a header file, every module that includes that header will be compilled as if the "a" is in a data, but it will actually be in idata and the compilled code will end up overwriting some other memory locations with what is intended to go to "a". The following code produced no error either, and probably even shouldn't, but the generated code is wrong again: --- extern idata char a; //in some header char a; //in some C module --- Now in all modules, except where "char a;" is defined, "a" is treated as being in idata, but in that module it defaults to data. I think such a definitions are correct: I think specifying "idata" in a declaration should be sufficient and repeating it in a definition should not be necessary (is this true?) The following code treats "a" as volatile everywhere except where it is defined: --- extern volatile char a; char a; ["a" is not volatile here - declaration is overridden by a definition, which is not good] --- I think this is a bug either. At least it took quite a some time of mine to figure out why my program crashes:) Here is an example that demonstrates the both problems: --- extern volatile char a; char a; extern idata char b; volatile char b; char main() { a = 5; b = 1; return a+b; } --- The generated asm follows: ---;var.c:7: a = 5; ; genAssign mov _a,#0x05 ;var.c:8: b = 1; ; genAssign mov _b,#0x01 [_b should be in idata, at least other modules will expect it to be there based on an extern decl] ;var.c:9: return a+b; ; genPlus mov a,#0x05 [must be "mov a,_a" since "a" is expected to be volatile - apparently it is not] add a,_b mov dpl,a ; genRet 00101$: ret --- SDCC is from CVS, testing the mcs51 port. $ sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400/hc08 2.3.6 (Nov 7 2003) (UNIX) ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2003-11-20 23:27 Message: Logged In: YES user_id=635249 Yes, it was forgotten debugging output; maybe I shouldn't stay up so late. It was displaying storage class (data, xdata, code, etc) for the previous and current declaration. The trickiest part of making sure the declarations match is that the storage class may not match at this point, but might match later. This is because the compiler modifies the types for some cases. For example: const int x; becomes const code int x; for global (level=0) variables int x; becomes xdata int x; for -mmcs51 --model-large So it was also displaying the current storage class as well as the anticipated final storage class. Anyway, src/SDCCsymt.c 1.168 no longer displays this extraneous information. ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2003-11-20 12:06 Message: Logged In: YES user_id=501371 Thank you for fixing the bug! There are some strange error messages however, compiling the following code: --- extern data char a[10]; idata char a[10]; int main() { return a[0]; } --- $ sdcc decls.c level = 0 SPEC_SCLS (src) = 8, SPEC_SCLS (dest) = 7 srcScls = 8, destScls = 7 decls.c:2: error: extern definition for 'a' mismatches with declaration. from type 'char data-[10] ' to type 'char idata-[10] ' -:0: error: code not generated for 'main' due to previous errors What do that messages stand for? Looks like a forgotten debug output. The test-case is attached. This is not a problem at all, just a strange messages:) ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2003-11-12 02:33 Message: Logged In: YES user_id=635249 Fixed with src/SDCCsymt.h 1.68 and src/SDCCsymt.c 1.167 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=838241&group_id=599 |