Hi and thank you again for replying to my e-mails!
On Tue, Mar 22, 2011 at 4:00 PM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> Radu Hobincu <radu.hobincu@xxxxxxxxxx> writes:
>
>> I'm trying to write a GCC backend for a custom RISC machine and
>> suddenly I seems to have a problem while compiling some C++ classes.
>> After changing some code from all the implementation in the header
>> file to declaration of the class in the header file and implementation
>> in the .cpp file, the compiler started asking me for a
>> STATIC_CHAIN_REGNUM. I'm a bit unfamiliar with this concept and google
>> didn't really help (altho I found out there's a band called Static
>> Chain...) so I was wondering if there are some links/ docs that
>> explain what this does.
>>
>> Anyway, after declaring the macro and adding/ fixing some rtx
>> templates in order to load a label into a register, now, when
>> compiling the cpp file, I get some strange calls to some functions
>> I've never seen before: __gxx_personality_sj0, _Unwind_SjLj_Resume,
>> _Unwind_SjLj_Unregister. I'm pretty sure these are functions defined
>> somewhere in libstdc++ but I have no idea what they do and I don't
>> know why they suddenly appeared now, after I split the code in
>> header/implementation.
>>
>> At the same time, some asm inlines which worked fine before started
>> givimg me "error: ‘asm’ operand requires impossible reload", but
>> however still work, as in they generate valid asm inline code.
>>
>> So, to summarize:
>> 1. what exactly is a static chain?
>
> First I'll say that you neglected to see which version of gcc you are
> using.
I'm sorry, the version is gcc-4.4.5.
>
> 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. However, as you
said, I have no nested functions in the code I want to compile. The
crash is due to the following function in my code:
vector shiftRight(vector _vector, int _cells, int _type = REPEAT, int
_fillValue = 0){
if(_cells > 0){
return shift(_vector, -_cells, _type, _fillValue);
}
return _vector;
}
where shift is another function.
This is the backtrace of the crash, in case it helps:
Program received signal SIGSEGV, Segmentation fault.
emit_clobber (x=0x0) at ../../gcc-4.4.5/gcc/emit-rtl.c:4703
4703 if (GET_CODE (x) == CONCAT)
(gdb) bt
#0 emit_clobber (x=0x0) at ../../gcc-4.4.5/gcc/emit-rtl.c:4703
#1 0x081388b0 in expand_builtin_setjmp_receiver
(receiver_label=0xb7939bf4) at ../../gcc-4.4.5/gcc/builtins.c:742
#2 0x0819677a in sjlj_emit_dispatch_table () at
../../gcc-4.4.5/gcc/except.c:1956
#3 sjlj_build_landing_pads () at ../../gcc-4.4.5/gcc/except.c:2037
#4 finish_eh_generation () at ../../gcc-4.4.5/gcc/except.c:2073
#5 0x08196da7 in rest_of_handle_eh () at ../../gcc-4.4.5/gcc/except.c:3958
#6 0x08260d86 in execute_one_pass (pass=0x8547840) at
../../gcc-4.4.5/gcc/passes.c:1277
#7 0x08260fdc in execute_pass_list (pass=0x8547840) at
../../gcc-4.4.5/gcc/passes.c:1326
#8 0x08260fef in execute_pass_list (pass=0x856ae60) at
../../gcc-4.4.5/gcc/passes.c:1327
#9 0x08300e8d in tree_rest_of_compilation (fndecl=0xb79a4100) at
../../gcc-4.4.5/gcc/tree-optimize.c:420
#10 0x083ef31b in cgraph_expand_function (node=0xb79a4180) at
../../gcc-4.4.5/gcc/cgraphunit.c:1047
#11 0x083f0637 in cgraph_expand_all_functions () at
../../gcc-4.4.5/gcc/cgraphunit.c:1106
#12 cgraph_optimize () at ../../gcc-4.4.5/gcc/cgraphunit.c:1310
#13 0x08096ac5 in cp_write_global_declarations () at
../../gcc-4.4.5/gcc/cp/decl2.c:3653
#14 0x082c69de in compile_file (argc=4, argv=0xbffff2f4) at
../../gcc-4.4.5/gcc/toplev.c:981
#15 do_compile (argc=4, argv=0xbffff2f4) at ../../gcc-4.4.5/gcc/toplev.c:2197
#16 toplev_main (argc=4, argv=0xbffff2f4) at ../../gcc-4.4.5/gcc/toplev.c:2229
#17 0x0812a86b in main (argc=4, argv=0xbffff2f4) at
../../gcc-4.4.5/gcc/main.c:35
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? :)
>> 2. why is that after splitting the code, calls to stdlibc++
>> suddenly appear, and is there a way to keep them from appearing?
>
> The functions you mention are used for exception handling. I would
> guess that when all the code is in the header file gcc was able to
> determine that no exceptions could occur, but when the definitions were
> moved out of the header file some exceptions became possible. If you
> want to write C++ code you need to either provide the functions which
> handle exceptions or you need to always compile with -fno-exceptions.
Beautiful, that worked like a charm, thank you! :)
>> 3. is the asm error a fatal error or can I live with it/ fix it?
>
> 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?
Radu
> Ian
>
