From: SourceForge.net <no...@so...> - 2009-06-04 14:17:15
|
Patches item #2801126, was opened at 2009-06-04 16:17 Message generated for change (Tracker Item Submitted) made by rlar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Larice (rlar) Assigned to: Nobody/Anonymous (nobody) Summary: __builtin_offsetof implementation Initial Comment: the current implementation of the offsetof macro depends on special code in SDCCast.c which causes problems for certain pointer casts. (see offsetof-bug.c testcase in the patch) this patch implements offsetof with a compiler builtin __builtin_offsetof to avoid this problem, and to avoid such special twisting of the ast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 |
From: SourceForge.net <no...@so...> - 2010-07-25 13:11:47
|
Patches item #2801126, was opened at 2009-06-04 16:17 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Robert Larice (rlar) >Assigned to: Borut Ražem (borutr) Summary: __builtin_offsetof implementation Initial Comment: the current implementation of the offsetof macro depends on special code in SDCCast.c which causes problems for certain pointer casts. (see offsetof-bug.c testcase in the patch) this patch implements offsetof with a compiler builtin __builtin_offsetof to avoid this problem, and to avoid such special twisting of the ast. ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2010-07-25 15:11 Message: Patch applied in svn revision #5888. Borut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 |
From: Robert L. <Rob...@t-...> - 2010-07-25 16:35:30
|
"SourceForge.net" <no...@so...> writes: > Patches item #2801126, was opened at 2009-06-04 16:17 > Message generated for change (Comment added) made by borutr > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None >>Status: Closed >>Resolution: Accepted > Priority: 5 > Private: No > Submitted By: Robert Larice (rlar) >>Assigned to: Borut Ražem (borutr) > Summary: __builtin_offsetof implementation > > Initial Comment: > the current implementation of the offsetof macro > depends on special code in SDCCast.c > which causes problems for certain pointer casts. > (see offsetof-bug.c testcase in the patch) > > this patch implements offsetof with a compiler > builtin __builtin_offsetof to avoid this problem, > and to avoid such special twisting of the ast. > > > ---------------------------------------------------------------------- > >>Comment By: Borut Ražem (borutr) > Date: 2010-07-25 15:11 > > Message: > Patch applied in svn revision #5888. > > Borut Hello Borut, Thank you for making use of that. The patch did contain two regression test files. Did you leave them out intentionally ? Or just forget to `add' them to the repository ? (those are of course `new' files) Robert |
From: Borut R. <bor...@si...> - 2010-07-25 16:59:02
|
Hi Robert, thanks for noticing it. I forgot to "svn add" the offsetof.c regression test file, so it wasn't committed. I corrected it. I didn't commit the file offsetof.c, since it fails the tegtest. It woks OK if I change it to: ---8<--- struct st { char a; }; char *__code* * correct() { return (char __code *) 0x1234; } char *__code* * buggy() { return &(((struct st __code *) 0x1234) -> a); } void testBug(void) { ASSERT(correct() == buggy()); } --->8--- but I don't know if the test makes sense any more!? Borut On 07/25/2010 06:31 PM, Robert Larice wrote: > "SourceForge.net"<no...@so...> writes: > > >> Patches item #2801126, was opened at 2009-06-04 16:17 >> Message generated for change (Comment added) made by borutr >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 >> >> Please note that this message will contain a full copy of the comment thread, >> including the initial issue submission, for this request, >> not just the latest update. >> Category: None >> Group: None >> >>> Status: Closed >>> Resolution: Accepted >>> >> Priority: 5 >> Private: No >> Submitted By: Robert Larice (rlar) >> >>> Assigned to: Borut Ražem (borutr) >>> >> Summary: __builtin_offsetof implementation >> >> Initial Comment: >> the current implementation of the offsetof macro >> depends on special code in SDCCast.c >> which causes problems for certain pointer casts. >> (see offsetof-bug.c testcase in the patch) >> >> this patch implements offsetof with a compiler >> builtin __builtin_offsetof to avoid this problem, >> and to avoid such special twisting of the ast. >> >> >> ---------------------------------------------------------------------- >> >> >>> Comment By: Borut Ražem (borutr) >>> >> Date: 2010-07-25 15:11 >> >> Message: >> Patch applied in svn revision #5888. >> >> Borut >> > Hello Borut, > > Thank you for making use of that. > > The patch did contain two regression test files. > Did you leave them out intentionally ? > Or just forget to `add' them to the repository ? > (those are of course `new' files) > > Robert > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Robert L. <Rob...@t-...> - 2010-07-25 17:50:14
|
Borut Razem <bor...@si...> writes: > Hi Robert, > > thanks for noticing it. I forgot to "svn add" the offsetof.c regression test file, so it wasn't committed. I corrected it. > > I didn't commit the file offsetof.c, since it fails the regtest. It woks OK if I change it to: > > ---8<--- > struct st { > char a; > }; > > char __code * correct() { return (char __code *) 0x1234; } > char __code * buggy() { return &(((struct st __code *) 0x1234) -> a); } > > void > testBug(void) > { > ASSERT(correct() == buggy()); > } > --->8--- > > but I don't know if the test makes sense any more!? > > Borut Borut, this second test (actually offsetof-bug.c) was meant to expose a bug, and how it got fixed with the patch applied. back then, a year ago, this worked. if it doesnt work now, that means there is again something else broken in sdcc. I thus consider this a *new* bug. there are a lot of bugs in the tracker having to do with such casts of literals to pointers. I'm not at all surprised. casting a literal, to a code pointer, and then implicit, to a generic pointer. I think thats worth a new bug entry. Robert --------- Just for the record, in case someone is going to investigate this, here is the original, now failing piece: +struct st { + char a; +}; + +char * correct() { return (char code *) 0x1234; } +char * buggy() { return &(((struct st code *) 0x1234) -> a); } + + +void +testBug(void) +{ + ASSERT(correct() == buggy()); +} |
From: Borut R. <bor...@si...> - 2010-07-25 17:00:10
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> Hi Robert,<br> <br> thanks for noticing it. I forgot to "svn add" the offsetof.c regression test file, so it wasn't committed. I corrected it.<br> <br> I didn't commit the file offsetof.c, since it fails the regtest. It woks OK if I change it to:<br> <br> ---8<---<br> struct st {<br> char a;<br> };<br> <br> char <b>__code</b> * correct() { return (char __code *) 0x1234; }<br> char <b>__code</b> * buggy() { return &(((struct st __code *) 0x1234) -> a); }<br> <br> <br> void<br> testBug(void)<br> {<br> ASSERT(correct() == buggy());<br> }<br> --->8---<br> <br> but I don't know if the test makes sense any more!?<br> <br> Borut<br> <br> <br> On 07/25/2010 06:31 PM, Robert Larice wrote: <blockquote cite="mid:kkv...@t-..." type="cite"> <pre wrap="">"SourceForge.net" <a class="moz-txt-link-rfc2396E" href="mailto:no...@so..."><no...@so...></a> writes: </pre> <blockquote type="cite"> <pre wrap="">Patches item #2801126, was opened at 2009-06-04 16:17 Message generated for change (Comment added) made by borutr You can respond by visiting: <a class="moz-txt-link-freetext" href="https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599">https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599</a> Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None </pre> <blockquote type="cite"> <pre wrap="">Status: Closed Resolution: Accepted </pre> </blockquote> <pre wrap="">Priority: 5 Private: No Submitted By: Robert Larice (rlar) </pre> <blockquote type="cite"> <pre wrap="">Assigned to: Borut Ražem (borutr) </pre> </blockquote> <pre wrap="">Summary: __builtin_offsetof implementation Initial Comment: the current implementation of the offsetof macro depends on special code in SDCCast.c which causes problems for certain pointer casts. (see offsetof-bug.c testcase in the patch) this patch implements offsetof with a compiler builtin __builtin_offsetof to avoid this problem, and to avoid such special twisting of the ast. ---------------------------------------------------------------------- </pre> <blockquote type="cite"> <pre wrap="">Comment By: Borut Ražem (borutr) </pre> </blockquote> <pre wrap="">Date: 2010-07-25 15:11 Message: Patch applied in svn revision #5888. Borut </pre> </blockquote> <pre wrap=""> Hello Borut, Thank you for making use of that. The patch did contain two regression test files. Did you leave them out intentionally ? Or just forget to `add' them to the repository ? (those are of course `new' files) Robert ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/sprint-com-first">http://p.sf.net/sfu/sprint-com-first</a> _______________________________________________ sdcc-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:sdc...@li...">sdc...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sdcc-devel">https://lists.sourceforge.net/lists/listinfo/sdcc-devel</a> </pre> </blockquote> <br> </body> </html> |
From: Borut R. <bor...@si...> - 2010-07-25 18:42:52
|
Robert, If I cmpile it without the __code *, I get the following error message for the line "char * correct() { return (char __code *) 0x1234; }": error 151: cannot use generic pointer to initialize <null> So I don't know if this is done by purpose (conversion from "specilaized" to generic pointer is not legal), or it is a bug? P.S.: The __code * in the line "char * buggy() { return &(((struct st __code *) 0x1234) -> a); }" is actually not needed, so the code which pass the test looks like: ---8<--- struct st { char a; }; char __code * correct() { return (char __code *) 0x1234; } char buggy() { return&(((struct st __code *) 0x1234) -> a); } void testBug(void) { ASSERT(correct() == buggy()); } --->8--- Borut On 07/25/2010 07:46 PM, Robert Larice wrote: > Borut Razem<bor...@si...> writes: > > >> Hi Robert, >> >> thanks for noticing it. I forgot to "svn add" the offsetof.c regression test file, so it wasn't committed. I corrected it. >> >> I didn't commit the file offsetof.c, since it fails the regtest. It woks OK if I change it to: >> >> ---8<--- >> struct st { >> char a; >> }; >> >> char __code * correct() { return (char __code *) 0x1234; } >> char __code * buggy() { return&(((struct st __code *) 0x1234) -> a); } >> >> void >> testBug(void) >> { >> ASSERT(correct() == buggy()); >> } >> --->8--- >> >> but I don't know if the test makes sense any more!? >> >> Borut >> > Borut, > > this second test (actually offsetof-bug.c) > was meant to expose a bug, and how it got fixed with the patch applied. > back then, a year ago, this worked. > > if it doesnt work now, that means there is again something else broken > in sdcc. I thus consider this a *new* bug. > there are a lot of bugs in the tracker having to do with > such casts of literals to pointers. I'm not at all surprised. > > casting a literal, to a code pointer, > and then implicit, to a generic pointer. > I think thats worth a new bug entry. > > Robert > > --------- > Just for the record, in case someone is going to investigate this, > here is the original, now failing piece: > > +struct st { > + char a; > +}; > + > +char * correct() { return (char code *) 0x1234; } > +char * buggy() { return&(((struct st code *) 0x1234) -> a); } > + > + > +void > +testBug(void) > +{ > + ASSERT(correct() == buggy()); > +} > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Robert L. <Rob...@t-...> - 2010-07-25 19:17:03
|
Borut Razem <bor...@si...> writes: > Robert, > > If I cmpile it without the __code *, I get the following error message > for the line "char * correct() { return (char __code *) > 0x1234; }": > > error 151: cannot use generic pointer to initialize <null> > > So I don't know if this is done by purpose (conversion from > "specilaized" to generic pointer is not legal), or it is a bug? Borut, so this *new* bug is at least a friendly one, doesn't segfault, doesn't produce garbage I'm too disconnected to have an Idea whats going on here, yet I'm confident this hasn't anything to do with the actual __builtin_offset implementation. Too be shure, one could obviously try this one liner char * correct() { return (char __code *) 0x1234; } on a recent commit, and see whether it compiled, which would mean somebody has allready tried to work around that plumbing somewhere else in sdcc. Perhaps I'm going to investigate it a bit, but don't expect anything soon. Robert |
From: Borut R. <bor...@si...> - 2010-07-25 20:16:59
|
Robert, this bug is a side effect of fixing#3027957. I submitted a new bug #3034400. Thanks for helping me, Borut On 07/25/2010 09:13 PM, Robert Larice wrote: > Borut Razem<bor...@si...> writes: > > >> Robert, >> >> If I cmpile it without the __code *, I get the following error message >> for the line "char * correct() { return (char __code *) >> 0x1234; }": >> >> error 151: cannot use generic pointer to initialize<null> >> >> So I don't know if this is done by purpose (conversion from >> "specilaized" to generic pointer is not legal), or it is a bug? >> > Borut, > > so this *new* bug is at least a friendly one, > doesn't segfault, doesn't produce garbage > > I'm too disconnected to have an Idea whats going on here, > yet I'm confident this hasn't anything to do with the actual > __builtin_offset implementation. > > Too be shure, one could obviously try this one liner > char * correct() { return (char __code *) 0x1234; } > on a recent commit, and see whether it compiled, > which would mean somebody has allready tried to work around > that plumbing somewhere else in sdcc. > > Perhaps I'm going to investigate it a bit, > but don't expect anything soon. > > Robert > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Robert L. <Rob...@t-...> - 2010-07-26 19:07:17
|
Borut Razem <bor...@si...> writes: > Hi Maarten and others, > > ... > My idea to solve the problem is the introduction of "pure generic > pointer"(TM), which is an additional memory type to __code, __date, > __xdata, ... memory types. The pure generic pointer will be generated > when the memory type is unknown, for example when assigning an integer > to a generic pointer: > ... Hello Borut, obviously, you will need a new type tag, for the mcs51 24 bit pointers. lets say, 0x50, thus void *p = (char*) 0x1010; would look like: 0x50 0x10 0x10 in memory; what should hapen, if you pass this pointer p around as arguments to some function calls. and somebody then tries to dereference it ? of course you will have a cast in the reverse direction as well: long foo = (long) p; what should the value of foo be ? 0x501010 or 0x1010 Robert |
From: Robert L. <Rob...@t-...> - 2010-07-26 20:16:05
|
Borut Razem <bor...@si...> writes: > On 07/26/2010 09:03 PM, Robert Larice wrote: >> Borut Razem<bor...@si...> writes: >> >> >>> Hi Maarten and others, >>> >>> ... >>> My idea to solve the problem is the introduction of "pure generic >>> pointer"(TM), which is an additional memory type to __code, __date, >>> __xdata, ... memory types. The pure generic pointer will be generated >>> when the memory type is unknown, for example when assigning an integer >>> to a generic pointer: >>> ... >>> >> Hello Borut, >> >> obviously, you will need a new type tag, >> for the mcs51 24 bit pointers. >> lets say, 0x50, >> >> > > I didn't think about this yet, but yes: there will be 16 bit pure > generic pointers and 24 bit pure generic pointers. > >> thus >> void *p = (char*) 0x1010; >> would look like: >> 0x50 0x10 0x10 >> in memory; >> >> what should hapen, if you pass this pointer >> p around as arguments to some function calls. >> and somebody then tries to dereference it ? >> >> > > Error message, saying that pure generic pointer can not be dereferenced. the dereference is happening in another function. the compiler can't know this. Do you want a runtime exception, in an embedded system ? only way out would be to forbid passing a "pure generic" pointer to functions. can get nasty. bar(bool flag, void *x) { void *y = flag ? x : (void*)0x1234; poke(y, 0xff); } basically you would have to forbid almost everything to be done with such "pure generic" pointers. actually this could be an escape anyway. simply don't allow (generic*) constant. with the exception of a literal `0' though, must work, per standard, and be NULL yet one would still like something like void *foo(long x) { return (void*) x; } and there again one would have to carefully consider foo(0) === NULL ? foo(0x401010) === mcs main memory[0x1010] ? foo(0x200010) === mcs sfr space[0x10] ? (please subsitute 0x20 0x40, I can't remember ...) and so on ... Robert |
From: Borut R. <bor...@si...> - 2010-07-26 20:38:35
|
On 07/26/2010 10:12 PM, Robert Larice wrote: > Borut Razem<bor...@si...> writes: > > >> On 07/26/2010 09:03 PM, Robert Larice wrote: >> >>> Borut Razem<bor...@si...> writes: >>> >>> >>> >>>> Hi Maarten and others, >>>> >>>> ... >>>> My idea to solve the problem is the introduction of "pure generic >>>> pointer"(TM), which is an additional memory type to __code, __date, >>>> __xdata, ... memory types. The pure generic pointer will be generated >>>> when the memory type is unknown, for example when assigning an integer >>>> to a generic pointer: >>>> ... >>>> >>>> >>> Hello Borut, >>> >>> obviously, you will need a new type tag, >>> for the mcs51 24 bit pointers. >>> lets say, 0x50, >>> >>> >>> >> I didn't think about this yet, but yes: there will be 16 bit pure >> generic pointers and 24 bit pure generic pointers. >> >> >>> thus >>> void *p = (char*) 0x1010; >>> would look like: >>> 0x50 0x10 0x10 >>> in memory; >>> >>> what should hapen, if you pass this pointer >>> p around as arguments to some function calls. >>> and somebody then tries to dereference it ? >>> >>> >>> >> Error message, saying that pure generic pointer can not be dereferenced. >> > the dereference is happening in another function. > the compiler can't know this. > > You just killed my theory :-( I didn't get what you mean in your previous post... > Do you want a runtime exception, in an embedded system ? > > This would be something like instantiate a C++ pure virtual function, which is also checked in the run time. I wonder how this is implemented in embedded systems. > only way out would be to forbid passing a "pure generic" pointer > to functions. > can get nasty. > > bar(bool flag, void *x) { > void *y = flag ? x : (void*)0x1234; > poke(y, 0xff); > } > > basically you would have to forbid almost everything > to be done with such "pure generic" pointers. > > actually this could be an escape anyway. > simply don't allow > (generic*) constant. > with the exception of a literal `0' though, > must work, per standard, and be NULL > > yet one would still like something like > void *foo(long x) { return (void*) x; } > and there again one would have to carefully consider > foo(0) === NULL ? > foo(0x401010) === mcs main memory[0x1010] ? > foo(0x200010) === mcs sfr space[0x10] ? > (please subsitute 0x20 0x40, I can't remember ...) > > and so on ... > > Robert > |
From: Maarten B. <sou...@ds...> - 2010-07-25 21:09:22
|
Hello Robert and Borut, This is my doing. I also stumbled on bug 1469031 yesterday with a discussion about the same issue. The agreement seemed to turn all these errors about generic pointers into warnings and let incorrect code be generated. Borut, can you please add your comment? Maarten > Robert, > > this bug is a side effect of fixing#3027957. I submitted a new bug #3034400. > Thanks for helping me, > > Borut > > > On 07/25/2010 09:13 PM, Robert Larice wrote: > > Borut Razem<bor...@si...> writes: > > > > > >> Robert, > >> > >> If I cmpile it without the __code *, I get the following error message > >> for the line "char * correct() { return (char __code *) > >> 0x1234; }": > >> > >> error 151: cannot use generic pointer to initialize<null> > >> > >> So I don't know if this is done by purpose (conversion from > >> "specilaized" to generic pointer is not legal), or it is a bug? > >> > > Borut, > > > > so this *new* bug is at least a friendly one, > > doesn't segfault, doesn't produce garbage > > > > I'm too disconnected to have an Idea whats going on here, > > yet I'm confident this hasn't anything to do with the actual > > __builtin_offset implementation. > > > > Too be shure, one could obviously try this one liner > > char * correct() { return (char __code *) 0x1234; } > > on a recent commit, and see whether it compiled, > > which would mean somebody has allready tried to work around > > that plumbing somewhere else in sdcc. > > > > Perhaps I'm going to investigate it a bit, > > but don't expect anything soon. > > > > Robert > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > |
From: Borut R. <bor...@si...> - 2010-07-26 18:28:01
|
Hi Maarten and others, until now I haven't express my opinion because I didn't have one: my knowledge about the problem was too shallow. But yesterday, while applying the __builtin_offsetof patch, I had to dig into the problem and now I think I understand it a little bit more. If I understand well, the main problem is assignment of an integer to a generic pointer: void *p = 0x1234; since it is not known which kind of memory (__code, __data, ...) it is supposed to point to (we don't know what the value of the additional byte of the generic pointer should be). Assignments like this: void *p = (__code *)0x1234; are not problematic, since the cast defines the kind of memory the pointer is pointing to (it defines the value of the additional byte of the generic pointer). My idea to solve the problem is the introduction of "pure generic pointer"(TM), which is an additional memory type to __code, __date, __xdata, ... memory types. The pure generic pointer will be generated when the memory type is unknown, for example when assigning an integer to a generic pointer: void *p = 0x1234; /* p is pure generic pointer */ All the pointer arithmetic will work on pure generic pointers as it does on other memory type pointers. The only thing that can not be done with pure generic pointer is dereference (accessing the memory location it points to), since the memory type it points to doesn't exist (or it is not known). I think such an implementation solves several problems: - the offsetof() implemented as a macro (only pinter arithmetic involved, no dereferencing) - no errors / warnings when assigning an integer to a generic pointer (C standard compliant) - error message will be shown only when trying to dereference the pure generic pointer - no danger to access the wrong memory, which would be the case with the proposition to change errors to warnings - (hopefully) easy implementation: the only places that should be modified in the sdcc source code are pointer assignment and pointer dereferencing. This can all be done on i-code level, so there is no need to touch anything in the target code generators (I hope I'm not wrong). - the idea Stas Sergeev expressed in comments for bug #1518273 "I think it is good to have an error when such a pointer is dereferenced, but not when it is only created. I think creating such a pointers should be perfectly legal." Borut On 07/25/2010 11:09 PM, Maarten Brock wrote: > Hello Robert and Borut, > > This is my doing. I also stumbled on bug 1469031 > yesterday with a discussion about the same issue. The > agreement seemed to turn all these errors about generic > pointers into warnings and let incorrect code be > generated. Borut, can you please add your comment? > > Maarten > > >> Robert, >> >> this bug is a side effect of fixing#3027957. I submitted a new bug #3034400. >> Thanks for helping me, >> >> Borut >> >> >> On 07/25/2010 09:13 PM, Robert Larice wrote: >> >>> Borut Razem<bor...@si...> writes: >>> >>> >>> >>>> Robert, >>>> >>>> If I cmpile it without the __code *, I get the following error message >>>> for the line "char * correct() { return (char __code *) >>>> 0x1234; }": >>>> >>>> error 151: cannot use generic pointer to initialize<null> >>>> >>>> So I don't know if this is done by purpose (conversion from >>>> "specilaized" to generic pointer is not legal), or it is a bug? >>>> >>>> >>> Borut, >>> >>> so this *new* bug is at least a friendly one, >>> doesn't segfault, doesn't produce garbage >>> >>> I'm too disconnected to have an Idea whats going on here, >>> yet I'm confident this hasn't anything to do with the actual >>> __builtin_offset implementation. >>> >>> Too be shure, one could obviously try this one liner >>> char * correct() { return (char __code *) 0x1234; } >>> on a recent commit, and see whether it compiled, >>> which would mean somebody has allready tried to work around >>> that plumbing somewhere else in sdcc. >>> >>> Perhaps I'm going to investigate it a bit, >>> but don't expect anything soon. >>> >>> Robert >>> |
From: Borut R. <bor...@si...> - 2010-07-26 19:43:19
|
On 07/26/2010 09:03 PM, Robert Larice wrote: > Borut Razem<bor...@si...> writes: > > >> Hi Maarten and others, >> >> ... >> My idea to solve the problem is the introduction of "pure generic >> pointer"(TM), which is an additional memory type to __code, __date, >> __xdata, ... memory types. The pure generic pointer will be generated >> when the memory type is unknown, for example when assigning an integer >> to a generic pointer: >> ... >> > Hello Borut, > > obviously, you will need a new type tag, > for the mcs51 24 bit pointers. > lets say, 0x50, > > I didn't think about this yet, but yes: there will be 16 bit pure generic pointers and 24 bit pure generic pointers. > thus > void *p = (char*) 0x1010; > would look like: > 0x50 0x10 0x10 > in memory; > > what should hapen, if you pass this pointer > p around as arguments to some function calls. > and somebody then tries to dereference it ? > > Error message, saying that pure generic pointer can not be dereferenced. > of course you will have a cast in the reverse > direction as well: > long foo = (long) p; > > what should the value of foo be ? > 0x501010 > or > 0x1010 > > I suppose 0x1010. The same as for pointers to other storage classes, for example: void *p = (__code char *p)0x1010; long foo = (long)p; Borut |
From: Maarten B. <sou...@ds...> - 2010-07-26 20:42:25
|
Hi, > >>> My idea to solve the problem is the introduction of "pure generic > >>> pointer"(TM), which is an additional memory type to __code, __date, > >>> __xdata, ... memory types. The pure generic pointer will be generated > >>> when the memory type is unknown, for example when assigning an integer > >>> to a generic pointer: > >> > >> obviously, you will need a new type tag, > >> for the mcs51 24 bit pointers. > >> lets say, 0x50, I also had 0x50 in mind. > > I didn't think about this yet, but yes: there will be 16 bit pure > > generic pointers and 24 bit pure generic pointers. I suspect there is no problem on systems with 16 bit generic pointers because I guess they are all Von Neumann-type. > >> thus > >> void *p = (char*) 0x1010; > >> would look like: > >> 0x50 0x10 0x10 > >> in memory; > >> > >> what should hapen, if you pass this pointer > >> p around as arguments to some function calls. > >> and somebody then tries to dereference it ? > > > > Error message, saying that pure generic pointer can not be dereferenced. > > the dereference is happening in another function. > the compiler can't know this. > > Do you want a runtime exception, in an embedded system ? Indeed, this might have to be checked at runtime, in gptrget/gptrput. Doable, but it may wreck an embedded system. > only way out would be to forbid passing a "pure generic" pointer > to functions. > can get nasty. > > bar(bool flag, void *x) { > void *y = flag ? x : (void*)0x1234; > poke(y, 0xff); > } > > basically you would have to forbid almost everything > to be done with such "pure generic" pointers. > > actually this could be an escape anyway. > simply don't allow > (generic*) constant. > with the exception of a literal `0' though, > must work, per standard, and be NULL This is the current state and people complain about it. > yet one would still like something like > void *foo(long x) { return (void*) x; } > and there again one would have to carefully consider > foo(0) === NULL ? > foo(0x401010) === mcs main memory[0x1010] ? > foo(0x200010) === mcs sfr space[0x10] ? > (please subsitute 0x20 0x40, I can't remember ...) If it should return back to 0x1010 I think we should use 0x00 for the type tag which is currently used for xdata. And that is on purpose so it might support banked xdata upto 0x3FFFFF. I think the solution is to allow casting ints (literal or not) to generic pointers (with tag 0x50) but issue warnings. According to the standard dereferencing such a pointer need not work and all warnings can be suppressed if one wants to. One can argue if the tag needs to be used when casting from a long int or not. Maarten |
From: Borut R. <bor...@si...> - 2010-07-27 07:57:31
|
Currently it seems that the problem arises when the compiler loses control over the storage class of the pinter: - inside the function which takes a generic pointer as a parameter compiler doesn't know if it is a "normal" generic pointer or a "pure" generic pointer, so it doesn't know if it can be dereferenced or not. - the second such situation is when the function returns a generic pointer. - are there other such situations? I'm playing with the Robert's idea: "only way out would be to forbid passing a "pure generic" pointer to functions." Maybe we shouldn't forbid passing a "pure generic" pointer to functions but throw a warning in situations where the compiler loses control. The message could look like: "The compiler lost the control over the pure generic pointer. The effect of dereferencing depends on gptrget / gptrput implementation". If we choose the tag value 0x50, then the near data memory will be addressed when dereferencing a pure generic pointer, but the user can change gptrget / gptrput functions to achieve whatever he wants. Now about the example: bar(bool flag, void *x) { void *y = flag ? x : (void*)0x1234; poke(y, 0xff); } the "pure generic pointer" should be propagated to the result: if any of the operands is a pure generic pointer, the result is pure generic pointer. But this means a lot of changes in the i-code generation :-(. A big problem is also with functions returning a generic pointer: the warning should be thrown on all calls to such a functions, since the compiler doesn't know in the returned generic pointer is pure or not: void *f(void); int main(void) { void *p; ... p = f(); // throw a warning since p may become pure ... } I think this is not acceptable :-(. Now about generic pointer to long conversion: the implementation of generic pointers with an additional tag byte is internal sdcc compiler implementation and should be hidden to the uses as much as possible. The tag values may also be changed in different sdcc versions (introducing pure generic pointers with tag 0x50 could be an example). void *p = (void *)0x1234; long v = (long)p; // v should be 0x1234 since: long v = 0x1234; assert(v == (long)(void *)v); Instead of: foo(0x401010); the users should use: foo((__code void *)0x1010); P.S.: I have a feeling that we are reinventing the wheal. How all this stuff is implemented in other compilers for Harvard architectures? Borut On 07/26/2010 10:42 PM, Maarten Brock wrote: > Hi, > > >>>>> My idea to solve the problem is the introduction of "pure generic >>>>> pointer"(TM), which is an additional memory type to __code, __date, >>>>> __xdata, ... memory types. The pure generic pointer will be generated >>>>> when the memory type is unknown, for example when assigning an integer >>>>> to a generic pointer: >>>>> >>>> obviously, you will need a new type tag, >>>> for the mcs51 24 bit pointers. >>>> lets say, 0x50, >>>> > I also had 0x50 in mind. > > >>> I didn't think about this yet, but yes: there will be 16 bit pure >>> generic pointers and 24 bit pure generic pointers. >>> > I suspect there is no problem on systems with 16 bit > generic pointers because I guess they are all Von > Neumann-type. > > >>>> thus >>>> void *p = (char*) 0x1010; >>>> would look like: >>>> 0x50 0x10 0x10 >>>> in memory; >>>> >>>> what should hapen, if you pass this pointer >>>> p around as arguments to some function calls. >>>> and somebody then tries to dereference it ? >>>> >>> Error message, saying that pure generic pointer can not be dereferenced. >>> >> the dereference is happening in another function. >> the compiler can't know this. >> >> Do you want a runtime exception, in an embedded system ? >> > Indeed, this might have to be checked at runtime, in > gptrget/gptrput. Doable, but it may wreck an embedded > system. > > >> only way out would be to forbid passing a "pure generic" pointer >> to functions. >> can get nasty. >> >> bar(bool flag, void *x) { >> void *y = flag ? x : (void*)0x1234; >> poke(y, 0xff); >> } >> >> basically you would have to forbid almost everything >> to be done with such "pure generic" pointers. >> >> actually this could be an escape anyway. >> simply don't allow >> (generic*) constant. >> with the exception of a literal `0' though, >> must work, per standard, and be NULL >> > This is the current state and people complain about it. > > >> yet one would still like something like >> void *foo(long x) { return (void*) x; } >> and there again one would have to carefully consider >> foo(0) === NULL ? >> foo(0x401010) === mcs main memory[0x1010] ? >> foo(0x200010) === mcs sfr space[0x10] ? >> (please subsitute 0x20 0x40, I can't remember ...) >> > If it should return back to 0x1010 I think we should use > 0x00 for the type tag which is currently used for xdata. > And that is on purpose so it might support banked xdata > upto 0x3FFFFF. > > I think the solution is to allow casting ints (literal > or not) to generic pointers (with tag 0x50) but issue > warnings. According to the standard dereferencing such a > pointer need not work and all warnings can be suppressed > if one wants to. One can argue if the tag needs to be > used when casting from a long int or not. > > Maarten > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Maarten B. <sou...@ds...> - 2010-07-27 08:27:56
|
Hi again, After some more thought, I've come to the conclusion that we don't need this extra tag nor a pure generic pointer. A cast of an integer (short or long) should simply be assigned to the generic pointer with a warning. And a generic pointer cast to an integer should include the tag (as is). If the user knows the tags he can put them in the integer. This assertion will hold for 24 bit generic pointers: assert(v & 0x00FFFFFF == (long)(void *)v); If the user dereferences the generic pointer and it points to the wrong memory, well too bad, but that is what undefined behaviour is all about. We simply need to document that the implementation-defined behaviour is undefined for these casts and that it will probably access xdata. If the standard says we must allow the user to do stupid things then I say we warn them but allow them to. Maarten > Currently it seems that the problem arises when the compiler loses > control over the storage class of the pinter: > - inside the function which takes a generic pointer as a parameter > compiler doesn't know if it is a "normal" generic pointer or a "pure" > generic pointer, so it doesn't know if it can be dereferenced or not. > - the second such situation is when the function returns a generic pointer. > - are there other such situations? > > I'm playing with the Robert's idea: "only way out would be to forbid > passing a "pure generic" pointer to functions." > > Maybe we shouldn't forbid passing a "pure generic" pointer to functions > but throw a warning in situations where the compiler loses control. The > message could look like: > > "The compiler lost the control over the pure generic pointer. The effect > of dereferencing depends on gptrget / gptrput implementation". > > If we choose the tag value 0x50, then the near data memory will be > addressed when dereferencing a pure generic pointer, but the user can > change gptrget / gptrput functions to achieve whatever he wants. > > Now about the example: > > bar(bool flag, void *x) { > void *y = flag ? x : (void*)0x1234; > poke(y, 0xff); > } > > the "pure generic pointer" should be propagated to the result: if any of > the operands is a pure generic pointer, the result is pure generic > pointer. But this means a lot of changes in the i-code generation :-(. > > A big problem is also with functions returning a generic pointer: the > warning should be thrown on all calls to such a functions, since the > compiler doesn't know in the returned generic pointer is pure or not: > > void *f(void); > > int main(void) > { > void *p; > ... > p = f(); // throw a warning since p may become pure > ... > } > > I think this is not acceptable :-(. > > > Now about generic pointer to long conversion: the implementation of > generic pointers with an additional tag byte is internal sdcc compiler > implementation and should be hidden to the uses as much as possible. The > tag values may also be changed in different sdcc versions (introducing > pure generic pointers with tag 0x50 could be an example). > > void *p = (void *)0x1234; > long v = (long)p; // v should be 0x1234 > > since: > > long v = 0x1234; > assert(v == (long)(void *)v); > > > Instead of: > foo(0x401010); > > the users should use: > foo((__code void *)0x1010); > > > P.S.: I have a feeling that we are reinventing the wheal. How all this > stuff is implemented in other compilers for Harvard architectures? > > Borut > > > On 07/26/2010 10:42 PM, Maarten Brock wrote: > > Hi, > > > > > >>>>> My idea to solve the problem is the introduction of "pure generic > >>>>> pointer"(TM), which is an additional memory type to __code, __date, > >>>>> __xdata, ... memory types. The pure generic pointer will be generated > >>>>> when the memory type is unknown, for example when assigning an integer > >>>>> to a generic pointer: > >>>>> > >>>> obviously, you will need a new type tag, > >>>> for the mcs51 24 bit pointers. > >>>> lets say, 0x50, > >>>> > > I also had 0x50 in mind. > > > > > >>> I didn't think about this yet, but yes: there will be 16 bit pure > >>> generic pointers and 24 bit pure generic pointers. > >>> > > I suspect there is no problem on systems with 16 bit > > generic pointers because I guess they are all Von > > Neumann-type. > > > > > >>>> thus > >>>> void *p = (char*) 0x1010; > >>>> would look like: > >>>> 0x50 0x10 0x10 > >>>> in memory; > >>>> > >>>> what should hapen, if you pass this pointer > >>>> p around as arguments to some function calls. > >>>> and somebody then tries to dereference it ? > >>>> > >>> Error message, saying that pure generic pointer can not be dereferenced. > >>> > >> the dereference is happening in another function. > >> the compiler can't know this. > >> > >> Do you want a runtime exception, in an embedded system ? > >> > > Indeed, this might have to be checked at runtime, in > > gptrget/gptrput. Doable, but it may wreck an embedded > > system. > > > > > >> only way out would be to forbid passing a "pure generic" pointer > >> to functions. > >> can get nasty. > >> > >> bar(bool flag, void *x) { > >> void *y = flag ? x : (void*)0x1234; > >> poke(y, 0xff); > >> } > >> > >> basically you would have to forbid almost everything > >> to be done with such "pure generic" pointers. > >> > >> actually this could be an escape anyway. > >> simply don't allow > >> (generic*) constant. > >> with the exception of a literal `0' though, > >> must work, per standard, and be NULL > >> > > This is the current state and people complain about it. > > > > > >> yet one would still like something like > >> void *foo(long x) { return (void*) x; } > >> and there again one would have to carefully consider > >> foo(0) === NULL ? > >> foo(0x401010) === mcs main memory[0x1010] ? > >> foo(0x200010) === mcs sfr space[0x10] ? > >> (please subsitute 0x20 0x40, I can't remember ...) > >> > > If it should return back to 0x1010 I think we should use > > 0x00 for the type tag which is currently used for xdata. > > And that is on purpose so it might support banked xdata > > upto 0x3FFFFF. > > > > I think the solution is to allow casting ints (literal > > or not) to generic pointers (with tag 0x50) but issue > > warnings. According to the standard dereferencing such a > > pointer need not work and all warnings can be suppressed > > if one wants to. One can argue if the tag needs to be > > used when casting from a long int or not. > > > > Maarten |
From: Borut R. <bor...@si...> - 2010-07-27 13:04:17
|
... and hi again ;-) , I don't like that the tag (and its value) is exposed and accessible to the user (see my concerns below), but it seems that this is the most fasible, easiest solution for implementation and involves the lowest risk from the code stability point of view, so I agree. All other options we discussed have a hole for the user stupidity ("stupidity hole"(TM) ;-) in a place or an other, so why don't allow him to do stupid thinks at the very source... R.I.P. pure generic pointers. Borut On 07/27/2010 10:27 AM, Maarten Brock wrote: > Hi again, > > After some more thought, I've come to the conclusion > that we don't need this extra tag nor a pure generic > pointer. A cast of an integer (short or long) should > simply be assigned to the generic pointer with a > warning. And a generic pointer cast to an integer should > include the tag (as is). If the user knows the tags he > can put them in the integer. This assertion will hold > for 24 bit generic pointers: > > assert(v& 0x00FFFFFF == (long)(void *)v); > > If the user dereferences the generic pointer and it > points to the wrong memory, well too bad, but that is > what undefined behaviour is all about. We simply need to > document that the implementation-defined behaviour is > undefined for these casts and that it will probably > access xdata. If the standard says we must allow the > user to do stupid things then I say we warn them but > allow them to. > > Maarten > > >> Currently it seems that the problem arises when the compiler loses >> control over the storage class of the pinter: >> - inside the function which takes a generic pointer as a parameter >> compiler doesn't know if it is a "normal" generic pointer or a "pure" >> generic pointer, so it doesn't know if it can be dereferenced or not. >> - the second such situation is when the function returns a generic pointer. >> - are there other such situations? >> >> I'm playing with the Robert's idea: "only way out would be to forbid >> passing a "pure generic" pointer to functions." >> >> Maybe we shouldn't forbid passing a "pure generic" pointer to functions >> but throw a warning in situations where the compiler loses control. The >> message could look like: >> >> "The compiler lost the control over the pure generic pointer. The effect >> of dereferencing depends on gptrget / gptrput implementation". >> >> If we choose the tag value 0x50, then the near data memory will be >> addressed when dereferencing a pure generic pointer, but the user can >> change gptrget / gptrput functions to achieve whatever he wants. >> >> Now about the example: >> >> bar(bool flag, void *x) { >> void *y = flag ? x : (void*)0x1234; >> poke(y, 0xff); >> } >> >> the "pure generic pointer" should be propagated to the result: if any of >> the operands is a pure generic pointer, the result is pure generic >> pointer. But this means a lot of changes in the i-code generation :-(. >> >> A big problem is also with functions returning a generic pointer: the >> warning should be thrown on all calls to such a functions, since the >> compiler doesn't know in the returned generic pointer is pure or not: >> >> void *f(void); >> >> int main(void) >> { >> void *p; >> ... >> p = f(); // throw a warning since p may become pure >> ... >> } >> >> I think this is not acceptable :-(. >> >> >> Now about generic pointer to long conversion: the implementation of >> generic pointers with an additional tag byte is internal sdcc compiler >> implementation and should be hidden to the uses as much as possible. The >> tag values may also be changed in different sdcc versions (introducing >> pure generic pointers with tag 0x50 could be an example). >> >> void *p = (void *)0x1234; >> long v = (long)p; // v should be 0x1234 >> >> since: >> >> long v = 0x1234; >> assert(v == (long)(void *)v); >> >> >> Instead of: >> foo(0x401010); >> >> the users should use: >> foo((__code void *)0x1010); >> >> >> P.S.: I have a feeling that we are reinventing the wheal. How all this >> stuff is implemented in other compilers for Harvard architectures? >> >> Borut >> >> >> On 07/26/2010 10:42 PM, Maarten Brock wrote: >> >>> Hi, >>> >>> >>> >>>>>>> My idea to solve the problem is the introduction of "pure generic >>>>>>> pointer"(TM), which is an additional memory type to __code, __date, >>>>>>> __xdata, ... memory types. The pure generic pointer will be generated >>>>>>> when the memory type is unknown, for example when assigning an integer >>>>>>> to a generic pointer: >>>>>>> >>>>>>> >>>>>> obviously, you will need a new type tag, >>>>>> for the mcs51 24 bit pointers. >>>>>> lets say, 0x50, >>>>>> >>>>>> >>> I also had 0x50 in mind. >>> >>> >>> >>>>> I didn't think about this yet, but yes: there will be 16 bit pure >>>>> generic pointers and 24 bit pure generic pointers. >>>>> >>>>> >>> I suspect there is no problem on systems with 16 bit >>> generic pointers because I guess they are all Von >>> Neumann-type. >>> >>> >>> >>>>>> thus >>>>>> void *p = (char*) 0x1010; >>>>>> would look like: >>>>>> 0x50 0x10 0x10 >>>>>> in memory; >>>>>> >>>>>> what should hapen, if you pass this pointer >>>>>> p around as arguments to some function calls. >>>>>> and somebody then tries to dereference it ? >>>>>> >>>>>> >>>>> Error message, saying that pure generic pointer can not be dereferenced. >>>>> >>>>> >>>> the dereference is happening in another function. >>>> the compiler can't know this. >>>> >>>> Do you want a runtime exception, in an embedded system ? >>>> >>>> >>> Indeed, this might have to be checked at runtime, in >>> gptrget/gptrput. Doable, but it may wreck an embedded >>> system. >>> >>> >>> >>>> only way out would be to forbid passing a "pure generic" pointer >>>> to functions. >>>> can get nasty. >>>> >>>> bar(bool flag, void *x) { >>>> void *y = flag ? x : (void*)0x1234; >>>> poke(y, 0xff); >>>> } >>>> >>>> basically you would have to forbid almost everything >>>> to be done with such "pure generic" pointers. >>>> >>>> actually this could be an escape anyway. >>>> simply don't allow >>>> (generic*) constant. >>>> with the exception of a literal `0' though, >>>> must work, per standard, and be NULL >>>> >>>> >>> This is the current state and people complain about it. >>> >>> >>> >>>> yet one would still like something like >>>> void *foo(long x) { return (void*) x; } >>>> and there again one would have to carefully consider >>>> foo(0) === NULL ? >>>> foo(0x401010) === mcs main memory[0x1010] ? >>>> foo(0x200010) === mcs sfr space[0x10] ? >>>> (please subsitute 0x20 0x40, I can't remember ...) >>>> >>>> >>> If it should return back to 0x1010 I think we should use >>> 0x00 for the type tag which is currently used for xdata. >>> And that is on purpose so it might support banked xdata >>> upto 0x3FFFFF. >>> >>> I think the solution is to allow casting ints (literal >>> or not) to generic pointers (with tag 0x50) but issue >>> warnings. According to the standard dereferencing such a >>> pointer need not work and all warnings can be suppressed >>> if one wants to. One can argue if the tag needs to be >>> used when casting from a long int or not. >>> >>> Maarten >>> > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Robert L. <Rob...@t-...> - 2010-07-27 16:52:11
|
Borut Razem <bor...@si...> writes: > ... and hi again ;-) , > > I don't like that the tag (and its value) is exposed and accessible to > the user (see my concerns below), but it seems that this is the most > fasible, easiest solution for implementation and involves the lowest > risk from the code stability point of view, so I agree. > > All other options we discussed have a hole for the user stupidity > ("stupidity hole"(TM) ;-) in a place or an other, so why don't allow him > to do stupid thinks at the very source... > > R.I.P. pure generic pointers. > > Borut Hello, so if I understand you correctly, you are now aiming for a cast p = (generic*) literal and p = (generic*) long_expression where the byte representation of p is identical to the least 24 bit of the right hand side ? I think thats a worthwhile goal. and if I remember correctly, thats mostly the status quo of sdcc. I've attached a regression test to describe this. Currently the l2g() seems to be intentionally forbidden. The rest seems to pass. Obviously one would like to extend this test with stuff like (void*)(__code*) 0x1234 and many other things. Another thing which I'd like to bring up is: the builtin_offset patch eliminates following code in src/SDCCast.c - /* handle offsetof macro: */ - /* #define offsetof(TYPE, MEMBER) \ */ - /* ((unsigned) &((TYPE *)0)->MEMBER) */ - if (IS_ADDRESS_OF_OP(tree->right) - && IS_AST_OP (tree->right->left) - && tree->right->left->opval.op == PTR_OP - && IS_AST_OP (tree->right->left->left) - && tree->right->left->left->opval.op == CAST - && IS_AST_LIT_VALUE(tree->right->left->left->right)) - { - symbol *element = getStructElement ( - SPEC_STRUCT (LETYPE(tree->right->left)), - AST_SYMBOL(tree->right->left->right) - ); - - if (element) - { - tree->type = EX_VALUE; - tree->opval.val = valCastLiteral ( - LTYPE (tree), - element->offset - + floatFromVal (valFromType (RTYPE (tree->right->left->left))) - ); - - TTYPE (tree) = tree->opval.val->type; - TETYPE (tree) = getSpec (TTYPE (tree)); - tree->left = NULL; - tree->right = NULL; - return tree; - } - } I think this code is responsible for some really nasty and most certainly unexpected abstract syntax tree ramifications. The intention was to transform (int)(&(struct fo*)0 -> thing) ===>>> (int) constant But it applies in other situations as well, and then with disaster. (void*)(&(struct fo*)0x401234 -> thing) Could be this is considerable reason for the long standing troubles with fixing bugs related to casts/structs/literals Robert /* Test generic <-> literal casts */ /* * (compile "FOO=-old SDCCFLAGS=--funsigned-char make -C .. ALL_PORTS=mcs51-large ALL_TESTS='./tests/t1.c'") * (compile "SDCCFLAGS=--funsigned-char make -C .. ALL_PORTS=mcs51-large ALL_TESTS='./tests/t1.c'") */ #include <testfwk.h> #include <stddef.h> union aux { void *p; long l; } aux; long g2l(void *p) { return (long) p; } // void *l2g(long x) { return (void*) x; } currently not allowed long g2l_bin(void *p) { aux.p=p; return aux.l & 0x00ffffff; } void *l2g_bin(long l) { aux.l=l; return aux.p; } void testThis(void) { ASSERT (0 == g2l(0)); ASSERT (0 == g2l(NULL)); ASSERT (0 == g2l_bin(0)); ASSERT (0 == g2l_bin(NULL)); // ASSERT (NULL == l2g(0)); ASSERT (NULL == l2g_bin(0)); ASSERT (0x401234 == g2l_bin(0x401234)); ASSERT ((void*)0 == l2g_bin(0)); ASSERT ((void*)0x401234 == l2g_bin(0x401234)); } |
From: SourceForge.net <no...@so...> - 2010-07-25 20:05:47
|
Patches item #2801126, was opened at 2009-06-04 16:17 Message generated for change (Settings changed) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Robert Larice (rlar) Assigned to: Borut Ražem (borutr) Summary: __builtin_offsetof implementation Initial Comment: the current implementation of the offsetof macro depends on special code in SDCCast.c which causes problems for certain pointer casts. (see offsetof-bug.c testcase in the patch) this patch implements offsetof with a compiler builtin __builtin_offsetof to avoid this problem, and to avoid such special twisting of the ast. ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2010-07-25 22:05 Message: The regression test offsetof-bug.c was not added due to the bug #3034400: cannot use generic pointer to initialize <null>. This bug remains open until #3034400 is added and the offsetof-bug.c regression test is added. Borut ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-07-25 15:11 Message: Patch applied in svn revision #5888. Borut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-10-16 19:57:26
|
Patches item #2801126, was opened at 2009-06-04 16:17 Message generated for change (Settings changed) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Robert Larice (rlar) Assigned to: Borut Ražem (borutr) Summary: __builtin_offsetof implementation Initial Comment: the current implementation of the offsetof macro depends on special code in SDCCast.c which causes problems for certain pointer casts. (see offsetof-bug.c testcase in the patch) this patch implements offsetof with a compiler builtin __builtin_offsetof to avoid this problem, and to avoid such special twisting of the ast. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-07-25 22:05 Message: The regression test offsetof-bug.c was not added due to the bug #3034400: cannot use generic pointer to initialize <null>. This bug remains open until #3034400 is added and the offsetof-bug.c regression test is added. Borut ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-07-25 15:11 Message: Patch applied in svn revision #5888. Borut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300599&aid=2801126&group_id=599 |