GCC backend development

[Ian Lance Taylor]

Radu Hobincu <radu.hobincu@arh.pub.ro> 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