Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1767885 ] Parameters lost from scope of intermediate inline function
|
From: SourceForge.net <no...@so...> - 2009-11-08 00:45:06
|
Bugs item #1767885, was opened at 2007-08-05 13:26 Message generated for change (Comment added) made by ppisa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1767885&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: C-Front End Group: None Status: Open Resolution: Works For Me Priority: 7 Private: No Submitted By: Pavel Pisa (ppisa) Assigned to: Erik Petrich (epetrich) Summary: Parameters lost from scope of intermediate inline function Initial Comment: If inline function calls another inline function, the calling inline function does not see its parameters. If there is global variable of same name, it hides problem. It seems, that same problem affects even local variables declared before function call. SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.3 #4892 (Aug 5 2007) sdcc --std-c99 --debug --dumpall -mmcs51 --model-large -o inline-test-1.rel -c inline-test-1.c ---------------------------------------------------------------------- >Comment By: Pavel Pisa (ppisa) Date: 2009-11-08 01:45 Message: Hello Martin and others, I have found a while to test patches and SDCC again a little. The result from my testing is, that your bug is different one then one I have tried to solve. The switch statement is problem in your case. The function inlining does not create labels correctly. It would worth to be fixed, but I am not sure if/when I find time for that. If the switch statement is commented out (in echo.c:SchedulerBasicP__TaskBasic__runTask and blinknotimertask.c:SchedulerBasicP__TaskBasic__runTask functions) then both source files compiles correctly to object files. The linking reports unresolved symbols ___nesc_atomic_start and ___nesc_atomic_end, which is expected, I do not have TiniOS environment there. It would worth to try, if the code really works as expected on real hardware/in simulator when inline attribute is removed from functions with switch statements. I have run testing of build of our uLUt library core (GSA and GAVL) with patched actual SDCC version and it works correctly. I have incorporated SDCC compatibility changes into uLUt GIT repository. http://ulan.git.sourceforge.net/git/gitweb.cgi?p=ulan/ulut;a=summary git://ulan.git.sourceforge.net/gitroot/ulan/ulut There are some obstacles to build whole library and special sdcc rules version has to be but most of the other functionalities do not make big sense for so small microcontrollers and even many of them can be corrected (use memcpy instead of aggregate assignment, reentrant attribute etc). So generally current SDCC with provided patches is much more suitable for our use. It is run for long distance, the my first inline corrections are many years old, but there is some progress. Best wishes, Pavel ---------------------------------------------------------------------- Comment By: Martin Leopold (mleopold) Date: 2009-09-30 13:37 Message: Hi All, It was suggested to me to try this patch sine the TinyOS 8051 project is very much in need of an 8051 compiler that does inlining. I've taken the patch out for a spin and not sure what to say - it doesn't compile my code right out of the box. But then again the auto-generated code that I'm trying to compile is a mess. Here's what I did: * I took the patches and applied them to the current SVN they applied cleanly and I compiled SDCC with no hickups. I haven't read or attempted to understand the patches. * I took two simple examples for TinyOS and ran them through the entire TinyOS toolchain which ends up with an app.c file with a bunch of very bizarre inline functions. * I fed this app.c through the newly compiled SDCC. What I see is the following: Both programs are compiled from C to asm by SDCC, but the assembly step of both programs fail with a whole lot of errors like the one below. If I drop the "inline" keyword (which is what I normally do) both compile and work just fine. app.asm:1548: Error: <u> undefined symbol encountered during assembly ... I've attached both applications for your amusement. Best regards, Martin Leopold ---------------------------------------------------------------------- Comment By: Pavel Pisa (ppisa) Date: 2009-08-09 22:11 Message: The proposed series solves inline functions in initializers processing 0001-Process-inline-function-expansion-even-in-block-vari.patch - This is required the functions in initializers has to be expanded 0002-Move-temporary-inline-return-value-storage-in-front.patch - Move temporary inline return value storage in front of declarators. This may be needed for correct functionality of expansion of inline functions block variable declarations and default values assignment. 0003-Support-for-better-AST-tree-debug-print.patch - this patch has been used to help debugging The result has not been tested much, but patched SDCC compiles all support libraries, Actual mcs51 port version of uLan http://ulan.sourceforge.net/ project and even GSA and GAVL code from uLUt library. Basic tests works in s51 simulator. This is big leap forward. If SDCC can be fully used with inlines and uLUt we can get rid of nasty macro machinery required for mcs51 support and this cleans up project in whole. ---------------------------------------------------------------------- Comment By: Pavel Pisa (ppisa) Date: 2008-08-28 15:24 Message: Logged In: YES user_id=523128 Originator: YES The behavior changed after close of #1864577 to report next error inline-test-1.c:9: error 20: Undefined identifier 'x' The change reverts previous changes introducing inlineFindMaxBlockno to solve #1731741. May it be, that blockno has to be increased to not lose scope of parameters some other way still. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1767885&group_id=599 |