error compiling libgcc with ported cross-compiler
I am porting gcc to a new target architecture, and have come across a
problem when the make process tries to compile libgcc. The error I get
is included below.
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it
only allows (mem (plus (reg ..) (const ..))), and forbids a second
level of memory reference.
I am (obviously) no gcc-expert by far, and have no idea how to tackle
this problem. Has anyone had a similar problem, or any pointers as to
how I can solve it?
The error message is:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
does not satisfy its constraints:
(insn 114 153 117
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1558 (set
(mem/c/i:SI (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -52 [0xffcc])) [0 D.2153+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SI 1 r1)) 3 {*movsi_internal} (nil)
(nil))
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: internal
compiler error: in final_scan_insn, at final.c:2410
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [libgcc/./_powidf2.o] Error 1
make[3]: Leaving directory `/cygdrive/c/home/risc/build/gcc/gcc'
Re: error compiling libgcc with ported cross-compiler
On 9/10/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
It's really very basic:
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
and in the .c-file:
bool
legitimate_address_p (enum machine_mode mode, rtx addr, bool strict
ATTRIBUTE_UNUSED)
{
return (legitimate_offset_address_p (mode, addr)
|| legitimate_nonoffset_address_p (mode, addr));
}
static bool
legitimate_nonoffset_address_p (enum machine_mode mode
ATTRIBUTE_UNUSED, rtx addr)
{
return (GET_CODE (addr) == REG && REG_OK_FOR_BASE_P (addr));
}
static bool
legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx addr)
{
rtx reg, offset;
if (GET_CODE (addr) != PLUS)
return false;
reg = XEXP (addr, 0);
offset = XEXP (addr, 1);
if ((GET_CODE (reg) == REG && REG_OK_FOR_BASE_P (reg))
&& legitimate_address_integer_p (offset, 0))
return true;
return false;
}
static bool
legitimate_address_integer_p (rtx addr, int offset ATTRIBUTE_UNUSED)
{
return (GET_CODE (addr) == CONST_INT
&& SMALL_INT (INTVAL (addr));
}
/Tomas
Re: error compiling libgcc with ported cross-compiler
Thanks a lot for your input, I think I understand some of that code better now.
I stumbled upon a solution last night, on realizing that the problem
was with the DFmode powidf2 and seeing that I had not defined the
movsf or movdf insns (because I thought I shouldn't need them, having
no HW floating point support).
Defining them solved the problem, but now I have a very similar one
with the complex arithmetic __mulsc3 function in libgcc:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
This time I'm not sure what to do though. Do I really have to define
complex movsc-insns? I haven't found any other ports doing that, so
I'm guessing there's something else I'm missing.
support for float/complex math in libgcc cross-compiled
(I'm turning this into a thread of it's own, it's really the
continuation of "error compiling libgcc with ported cross-compiler"
from yesterday.)
I am porting GCC to a new target, and got the following error when
cross-compiling libgcc towards the end of the make process:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
I had a very similar problem some days ago, in the __powidf2 function,
and then the solution was to define the movsf insn.
This time I'm not sure what to do though. The problem now seems to be
with complex number, but do I really have to define complex
movsc-insns? I haven't found any other ports doing that, so I'm
guessing there's something else I'm missing.
What is really needed in terms of insns or target macros to support
the various types of math of libgcc? Am I missing some insn for moving
from SFmode to SImode?
Re: error compiling libgcc with ported cross-compiler
On 9/11/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote: >You shouldn't define them, they'll only hide the problem. You're right, and getting REG_OK_STRICT right solved the problem! That was probably the best answer I have ever gotten to any question I've asked online, by the way. Thank you very much for taking your time!
porting problem: segfault when compiling programs that call malloc
I am porting gcc to a new architecture, and have yet another problem that I've been staring at for far too long now. Whenever I compile a program that calls malloc, GCC crashes with: /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c: In function '__register_frame': /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c:119: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [libgcc/./unwind-dw2-fde.o] Error 1 (this example is from compiling libgcc, but the exact same thing happens for any file that calls malloc). I've looked at it in gdb and the error occurs in expand_call() in gcc/calls.c, at line 2787: rtx temp = gen_reg_rtx (GET_MODE (valreg)); where valreg is a null pointer. I've looked at the source, but I really can't see why it would be anything other than zero at that point, so I don't understand what is causing this. Does anyone have an idea about where to look for the cause of the problem?
Re: porting problem: segfault when compiling programs that call malloc
On 13 Sep 2007 13:45:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > valreg is set around line 2564 of calls.c. It shouldn't be zero at > line 2787. Unless you have an malloc function with a return type of > void, which seems dubious. Ok, do you have any idea about what might cause this to happen? Could it be something wrong with exception handling or dwarf2 debugging output? Or possibly varargs handling? I am complete lost here unfortunately... Other function calls work just fine.
porting problem again: ICE in add_clobbers
I am still porting gcc v4.1.2 to a new risc architecture, and this
time my problem is that when compiling with -O2 turned on, every insn
with a (use ..) side effect expression, eg.
(define_expand "sibcall"
[(parallel [(call (match_operand 0 "" "")
(match_operand 1 "" ""))
(use (match_operand 2 "" ""))
(use (match_operand 3 "" ""))])]
"TARGET_SIBCALL"
{
if (operands[3] == NULL_RTX)
operands[3] = const0_rtx;
internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
DONE;
})
causes the compiler to fail with an internal compiler error in add_clobbers.
I have looked at it in gdb and it fails on reaching the
gcc_unreachable() in add_clobbers, which happens because add_clobbers
is called (at combine.c:9576) with an insn_code_number that it does
not recognize.
Everything works fine when optimization is turned off. What is it that
gcc does differently when optimizing, that might cause this to happen?
Re: porting problem again: ICE in add_clobbers
I have investigated it further, and thought I'd add it to my question.
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if optimize > 0. Unfortunately, this is checked for all
over the source, and I still have no idea where to start looking, so
if anyone recognizes this, please let me know!
My original question is included below. The optimization switches I've
turned on are:
-falign-functions -falign-jumps -falign-loops -falign-labels
-freorder-blocks -fdefer-pop -fdelayed-branch
-fguess-branch-probability -fcprop-registers -floop-optimize
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants -fthread-jumps -fcrossjumping
-foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse
-fgcse-lm -fgcse-sm -fgcse-las -fexpensive-optimizations
-fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt
-fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
-fdelete-null-pointer-checks -freorder-functions -ftree-vrp -ftree-pre
-fomit-frame-pointer -fforce-mem
On 9/18/07, Tomas Svensson <[EMAIL PROTECTED]> wrote:
> I am still porting gcc v4.1.2 to a new risc architecture, and this
> time my problem is that when compiling with -O2 turned on, every insn
> with a (use ..) side effect expression, eg.
>
> (define_expand "sibcall"
> [(parallel [(call (match_operand 0 "" "")
> (match_operand 1 "" ""))
> (use (match_operand 2 "" ""))
> (use (match_operand 3 "" ""))])]
> "TARGET_SIBCALL"
> {
> if (operands[3] == NULL_RTX)
> operands[3] = const0_rtx;
>
> internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
> DONE;
> })
>
> causes the compiler to fail with an internal compiler error in add_clobbers.
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
>
> Everything works fine when optimization is turned off. What is it that
> gcc does differently when optimizing, that might cause this to happen?
>
Re: porting problem again: ICE in add_clobbers
On 9/18/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > Tomas Svensson wrote: > There is no optimization at all without -O, no matter how many -f > options you use. What you want to do is -O -fno-foo -fno-bar etc. > However, we do not have -f options for every optimization, so there is > no guarantee that this will identify the optimization pass that exposes > the bug in your port. Right, thanks. I sure hope I learn from all these silly mistakes... Anyway, I did the same thing again, this time with starting with the -O2 that causes the problem and turning off options with -fno- flags. This time, I found the compilation to work with '-O2 -fno-gcse' but to break with just '-O2'. So I guess the problem is somehow caused by global common subexpression elimination. Could it be that gcse changes the insn in some way, making it unrecognizable by the usual define_insn's? Should I use (unspec ..) or (clobber ..) instead of (use ..) (as suggested in GCC Internals, Side effects)? If so, what is the difference, really?
Re: porting problem again: ICE in add_clobbers
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > gcse will never convert a recognizable insn into an unrecognizable > insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? > You still haven't showed us the actual insn which failed to match. > > The problem is that whatever that insn looks like, there is no > define_insn which matches it. For purposes of matching, a > define_expand does not count. One example is (define_expand "bleu" [(use (match_operand 0 "" ""))] "" "expand_branch (LEU, operands[0]); DONE;") which is heavily inspired by the or32 port of version 3.4.4, as is expand_branch(). But this should not need a matching insn, since it ends in a DONE;, right? Or am I missing something again?
specifying insn costs from attributes
In the .md-file of my port, I have set an attribute "size" of every insn, giving its size (obviously), in bytes. Is there any way I can use the value of this attribute to determine the cost (in e.g. TARGET_RTX_COSTS) when optimizing for size? Or is there some other smart way of achieving the same thing? Is it better to use the "length" attribute for this?
