On 30 August 2006 15:11, kernel coder wrote:
> hi,
> I'm having some problem during build up of libgcc2 in function
> __floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
> backend.The error is
>
> ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
> ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation
> fault
This is always the first sign of a bug in your backend, as it's the first
bit of code that gets compiled for the target by the newly-compiled backend.
In this case, it's a really bad bug, because we're bombing out with a SEGV,
rather than getting a nice assert. This could be because of dereferencing a
null pointer.
> before crash following pattern is called
>
> (define_expand "cmp<mode>"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp<mode> \n");
> branch_cmp[0] = operands[0];
> branch_cmp[1] = operands[1];
> debug_rtx(branch_cmp[0]);
> debug_rtx(branch_cmp[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 4)
> (subreg:SI (reg:DI 25 [ u.0 ]) 4)
>
> after this i think it tries to mach some s bCOND pattern but in this
> case it fails .
>
> Is this my proposition correct?
Unlikely. You'd expect to see a proper ICE message with backtrace if recog
failed.
> In another working case where no error is being generated.Following is
> the sequence of called patterns
>
> (define_expand "cmp<mode>"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp<mode> \n");
> cmp_operands[0] = operands[0];
> cmp_operands[1] = operands[1];
> debug_rtx(cmp_operands[0]);
> debug_rtx(cmp_operands[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 0)
> (subreg:SI (reg:DI 25 [ u.0 ]) 0)
>
> Then the following pattern is matched
>
> (define_expand "bltu"
> [(set (pc)
> (if_then_else (ltu (cc0) (const_int 0))
> (label_ref (match_operand 0 ""))
> (pc)))]
> ""
> {
> fprintf(stderr,"\n branch_fp 8 bltu\n");
> })
> I've tried my best to track the problem but could not due my limited
> knowledge.Would you please give me some hint to debug the problem .
I suspect that what's going wrong is that, in the error case, one of the
'branch_cmp' or 'cmp_operands' arrays is getting set, but when the branch
pattern comes to be matched, it is the /other/ array that is used, which is
where the null pointer is coming from.
You've given no information about what you've actually changed, and I'm no
MIPS expert, but in my local copy of the gcc 4 sources there's no such thing
as 'branch_cmp', only 'cmp_operands', whereas in gcc series 3m, it's the other
way round
So I'm guessing that you've added a new variant of the cmp<mode> expander,
and you've based it on some old code from a series 3 version of the compiler,
and it's not good in series 4?
cheers,
DaveK
--
Can't think of a witty .sigline today....
