Radu Hobincu <radu.hobincu@xxxxxxxxxx> writes: >> The static chain is used by a nested function to refer to variables >> defined in the enclosing function. ÂI don't know what you mean when you >> say that the compiler started asking you for a STATIC_CHAIN_REGNUM. >> Normally if a backend does not define STATIC_CHAIN_REGNUM, and you write >> code using a nested function, the compiler will give the error "nested >> functions not supported on this target". ÂYou should of course only see >> that error if you write code that uses nested functions. ÂNested >> functions are a C extension. ÂI don't know of any way that you can >> trigger this error in C++ code. > > What I mean by asking me for it is that when trying to compile the > split code, the compiler crashed with a segmentation fault. After > using gdb on it, I found out that the crash was due to a call to > emit_clobber in emit-rtl.c:4703 with a null argument. Looking down the > stack trace, I ended up in expand_builtin_setjmp_receiver function, in > builtins.c:742 which calls emit_clobber(static_chain_rtx). When > looking where this static_chain_rtx is defined, I ended up in > emit-rtl.c where the static_chain_rtx is defined either as > > #ifdef STATIC_CHAIN_REGNUM > static_chain_rtx = gen_rtx_REG (Pmode, STATIC_CHAIN_REGNUM); > > #ifdef STATIC_CHAIN_INCOMING_REGNUM > if (STATIC_CHAIN_INCOMING_REGNUM != STATIC_CHAIN_REGNUM) > static_chain_incoming_rtx > = gen_rtx_REG (Pmode, STATIC_CHAIN_INCOMING_REGNUM); > else > #endif > static_chain_incoming_rtx = static_chain_rtx; > #endif > > or as > > #ifdef STATIC_CHAIN > static_chain_rtx = STATIC_CHAIN; > > #ifdef STATIC_CHAIN_INCOMING > static_chain_incoming_rtx = STATIC_CHAIN_INCOMING; > #else > static_chain_incoming_rtx = static_chain_rtx; > #endif > #endif > > and neither of the 2 macros were defined in my target. OK, that code got cleaner in gcc 4.5. What is happening here is not a nested function, it's that the setjmp exception receiver explicitly clobbers the static chain. In gcc 4.5 that works even if the target doesn't define a static chain. So this doesn't imply a nested function, it just implies an exception. > I just noticed, that after using the -fno-exceptions, all the above > problems disappear. No static_chain required, no asm failed reloads, > no nothing. So I guess it's all good? :) Yes, assuming you don't want to support exceptions. There is quite a bit of C++ code which uses exceptions, of course. >> An "impossible reload" error is indeed an error and can not be ignored. >> gcc will try to carry on by simply deleting the erroneous instruction, >> so your program will not work as expected. > > Hmm, that's bad. So basically an impossible reload means the compiler > can't load the expression in a hard reg of the class provided? So in > this case > > __asm__ __volatile__( > "rshr %0,%1" > : > :"v" (_result), "r" (_cells) > ); > > either _result or _cells can't be loaded in a "v" / "r" register? > > This disappeared after using -fno-exceptions. Is there a connection > between exceptions and nested functions somehow? The nested functions thing was a red herring, sorry. The error message "'asm' operand requires impossible reload" implies that the value in _result or _cells is somehow incompatible with the "v" or "r" constraint. It's hard to say more without a complete test case. Ian
