This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: assign_temp at function.c
BIGGEST_ALIGNMENT was 128 because i'm porting it from MIPS-gcc.
after changing it to 32, it works. But still not compiled whole
newlib. ( needs some minor rev)
Thank you Ian.
On Wed, Sep 30, 2009 at 4:01 PM, Ian Lance Taylor <iant@google.com> wrote:
> "Kim, Eunchan" <helpbygrace@gmail.com> writes:
>
>> ?__sprint_r _svfprintf_r
>> Program received signal SIGSEGV, Segmentation fault.
>> assign_temp (type_or_decl=0x0, keep=0, memory_required=1,
>> dont_promote=1) at ../../../sdk/gcc-4.3.3/gcc/function.c:807
>> 807 ? ? ? if (DECL_P (type_or_decl))
>> (gdb) bt
>> #0 ?assign_temp (type_or_decl=0x0, keep=0, memory_required=1,
>> dont_promote=1) at ../../../sdk/gcc-4.3.3/gcc/function.c:807
>> #1 ?0x0814d05c in emit_push_insn (x=0xb79ba038, mode=DFmode, type=0x0,
>> size=0xb79bc240, align=32, partial=0, reg=0x0, extra=0,
>> ? ? args_addr=0xb79be2a0, args_so_far=0xb79bc200,
>> reg_parm_stack_space=0, alignment_pad=0xb79bc200)
>> ? ? at ../../../sdk/gcc-4.3.3/gcc/expr.c:3731
>> #2 ?0x080cb966 in emit_library_call_value_1 (retval=1,
>> orgfun=0xb76ec4f0, value=0x0, fn_type=LCT_CONST, outmode=SImode,
>> ? ? nargs=3, p=0xbff14764 "") at ../../../sdk/gcc-4.3.3/gcc/calls.c:3730
>
>
>> two segmentation faults occurs at the same function, assign_temp.
>>
>> as you see, assign_temp requires tree parameter, but in the message
>> above, the tree parameter is NULL. ?in the assign_temp, it seems to
>> access the member of the tree. As a result, the pointer goes out of
>> bound, So it results SIGSEGV.
>>
>> I think this is occurred by my mistake in target.h or target.md . Does
>> anyone know why this happens? I'm digging this problem without any
>> achievement for 2 days :(
>
>
> I think this can only happen if you are passing some argument to a
> libcall that the code is not prepared to handle. ?Either you are
> passing a struct, or you are passing a large object which requires an
> alignment greater than that provided by the stack.
>
> Make sure that BIGGEST_ALIGNMENT is correct.
>
> Ian
>