From: Maarten B. <sou...@ds...> - 2007-05-06 08:21:51
|
How strange, I saw them here too but while hunting it down it disappeared. So I suspected an old build. I removed device/lib/build/z80/printf_large.* several times and let it rebuild. Nevertheless I will look into it today. > Maarten, > > we have new regression test failures :-( . > See > http://sdcc.sourceforge.net/regression_test_results/ppc-apple-macosx/regression-test-ppc-apple-macosx-20070506-4787.log > > This is definitely a show stopper... > I suppose that this is a consequence of new z80 peephole rules. If there > is no other solution, we cold undo the changes. > > Borut > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Erik P. <epe...@iv...> - 2007-05-08 03:53:23
|
On Sat, 5 May 2007, Borut Razem wrote: > > I think it is time to announce a feature freeze after > > Erik has blessed the 'inline' feature. > > > > > > This is also my opinion. Erik, when do you think you'll be ready? It's taking a bit longer than I expected to get the loose ends completely working. The main problem is how symbols are added to the symbol table during parsing, bound during AST processing, and then disposed (or modified, in the case of function parameters) by the end of the function's parsing. In some cases, a function needs to be generated long after it normally would have been (for example, a later function uses the address-of operator on an earlier function declared as static inline) and in this case I'm having difficulty recovering the correct binding for the parameter symbols. I'm coming to the conclusion that to make this work well, I'll need to make some changes that are bigger than I would feel comfortable making right before a new release. So I suggest we leave the inlining in its current state for this release and just label it as preliminary or alpha quality. As far as I know, the current inlining code works correctly for tbe most common cases. I have not, however, tried to use it in illegal ways to verify that these cases issue proper error messages. Erik |
From: Maarten B. <sou...@ds...> - 2007-05-08 07:09:24
|
Erik, If you use the address of on an inline function, couldn't we just throw an error? For the rest I agree. Maarten > > On Sat, 5 May 2007, Borut Razem wrote: > > > > I think it is time to announce a feature freeze after > > > Erik has blessed the 'inline' feature. > > > > > > > > > > This is also my opinion. Erik, when do you think you'll be ready? > > It's taking a bit longer than I expected to get the loose ends completely > working. The main problem is how symbols are added to the symbol table > during parsing, bound during AST processing, and then disposed (or > modified, in the case of function parameters) by the end of the function's > parsing. In some cases, a function needs to be generated long after it > normally would have been (for example, a later function uses the > address-of operator on an earlier function declared as static inline) and > in this case I'm having difficulty recovering the correct binding for the > parameter symbols. > > I'm coming to the conclusion that to make this work well, I'll need to > make some changes that are bigger than I would feel comfortable making > right before a new release. So I suggest we leave the inlining in its > current state for this release and just label it as preliminary or alpha > quality. As far as I know, the current inlining code works correctly for > tbe most common cases. I have not, however, tried to use it in illegal > ways to verify that these cases issue proper error messages. > > Erik > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Erik P. <epe...@iv...> - 2007-05-08 13:48:56
|
On Tue, 8 May 2007, Maarten Brock wrote: > If you use the address of on an inline function, > couldn't we just throw an error? I've looked through the C99 standard (as well as the associated corrigenda, defect reports, and rationale) quite a bit, but I can't find anything that says that taking the address of an inlined function is illegal. So I am forced to conclude that it must be legal. Erik |
From: David B. <dba...@ed...> - 2007-05-08 14:15:23
|
----- Original Message ----- From: "Erik Petrich" <epe...@iv...> To: <sou...@ds...>; "Development chatter about sdcc" <sdc...@li...> Sent: Tuesday, May 08, 2007 9:05 AM Subject: Re: [sdcc-devel] Plan for sdcc 2.7.0 > > On Tue, 8 May 2007, Maarten Brock wrote: > >> If you use the address of on an inline function, >> couldn't we just throw an error? > > I've looked through the C99 standard (as well as the associated > corrigenda, defect reports, and rationale) quite a bit, but I can't find > anything that says that taking the address of an inlined function is > illegal. So I am forced to conclude that it must be legal. The error doesn't need to say it's illegal, just that it's unsupported. I think that's what Maarten was getting at. Anyway, I would think if someone takes the address of an inline function, the compiler should create a non-inlined version and return its address. Or from the other direction, the compiler might always create a non-inline version and let the linker remove it if it's never accessed. (I see that Peter Miller just said almost the same thing). I considered almost the same issue when I was trying to figure out how to implement Feature Request [1483474], "Efficient Constants": http://sourceforge.net/tracker/index.php?func=detail&aid=1483474&group_id=599&atid=350599 David |
From: Peter M. <pm...@pe...> - 2007-05-08 12:34:20
|
SDCC needs to do what the C99 standard says inline will do. The C99 standard says that inline is only a suggestion to the C compiler. The C compiler can choose not to inline anything, and instead call the actual function. This means you can always take the address of an inline function, and it refers to an actual function. Doing anything that does not conform the C99 standard will result in a bug report. Taking the address of an inline function (static or not) causes it to be "outlined" (if it hasn't been already) so that it has an address. Usually, it is the linker's job to figure that the "outlined" version is never used, and omit it from the final binary. Not that they all do. Figuring that there are N identical definitions and omit N-1 of them is even harder; many linkers figure it doesn't matter and bloat the binary... but in embedded code it *really* does matter. On Tue, 2007-05-08 at 09:09 +0200, Maarten Brock wrote: > Erik, > > If you use the address of on an inline function, > couldn't we just throw an error? > > For the rest I agree. > > Maarten > > > > > On Sat, 5 May 2007, Borut Razem wrote: > > > > > > I think it is time to announce a feature freeze after > > > > Erik has blessed the 'inline' feature. > > > > > > > > > > > > > > This is also my opinion. Erik, when do you think you'll be ready? > > > > It's taking a bit longer than I expected to get the loose ends completely > > working. The main problem is how symbols are added to the symbol table > > during parsing, bound during AST processing, and then disposed (or > > modified, in the case of function parameters) by the end of the function's > > parsing. In some cases, a function needs to be generated long after it > > normally would have been (for example, a later function uses the > > address-of operator on an earlier function declared as static inline) and > > in this case I'm having difficulty recovering the correct binding for the > > parameter symbols. > > > > I'm coming to the conclusion that to make this work well, I'll need to > > make some changes that are bigger than I would feel comfortable making > > right before a new release. So I suggest we leave the inlining in its > > current state for this release and just label it as preliminary or alpha > > quality. As far as I know, the current inlining code works correctly for > > tbe most common cases. I have not, however, tried to use it in illegal > > ways to verify that these cases issue proper error messages. > > > > Erik > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |