unable to find a register to spill in class
Hi All,
I'm pretty new in porting and understunding GCC. I am trying to port gcc
4.02 to the DLX procesor by using dlx port for gcc 2.7.3.
Now I have the following problem:
. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o
../../gcc/libgcc2.c: In function â__muldi3â:
../../gcc/libgcc2.c:535: error: unable to find a register to spill in class
GR_REGS
../../gcc/libgcc2.c:535: error: this is the insn:
(insn 6 15 9 0 ../../gcc/libgcc2.c:526 (set (reg/f:SI 82 [ D.1307 ])
(mem/f/i:SI (reg/f:SI 30 r30) [6 D.1307+0 S4 A32])) 40
{movsi_general} (nil)
(expr_list:REG_EQUIV (mem/f/i:SI (reg/f:SI 30 r30) [6 D.1307+0 S4 A32])
(nil)))
../../gcc/libgcc2.c:535: confused by earlier errors, bailing out
I'm stucked here for almost a week. If you need more data please let me know
and I'll send them to this list.
I was trying with -da optionn but I'don't understand .greg file format.
Thanks,
Nemanja
static inline function body is missing
Hi all,
In my GCC 4.02 port for DLX cpu I'm expiriencing strange problem.
When compiling following example:
static inline int bar(void)
{
return 1;
}
int main()
{
int i = 0;
i = bar();
return i;
}
with the following line
dlx-elf-gcc -S foo.c
there is no bar() function body, but there is call of that function in
main().
Code is correct (bar() function body is there) when compiling with the
following line:
dlx-elf-gcc -S foo.c -funit-at-a-time
Is it possible to workaround this problem in my port files.
Thanks in advance,
Nemanja Popov
Re: static inline function body is missing
Thanks on answer. I'll try to do something similar. Cheers - Original Message - From: "Mike Stump" <[EMAIL PROTECTED]> To: "Nemanja Popov" <[EMAIL PROTECTED]> Cc: "GCC Development" Sent: Friday, February 24, 2006 10:31 PM Subject: Re: static inline function body is missing On Feb 24, 2006, at 2:08 AM, Nemanja Popov wrote: Is it possible to workaround this problem in my port files. Sounds like a bug, I'd recommend just finding and fixing the bug. Can't imagine it is more than a line to fix. Watch for TREE_USED, SYMBOL_REF_USED, mark_referenced, mark_decl_referenced I'd compile up a port that works (x86-linux maybe), and see where you go wrong compared to it. A watch point on that bit in the DECL will stop as it changes on linux, you can then go up and set breakpoints and compare. I'll give you an example of a bit from ppc darwin. In print_operand, we do: /* Mark the decl as referenced so that cgraph will output the function. */ if (SYMBOL_REF_DECL (x)) mark_decl_referenced (SYMBOL_REF_DECL (x)); during printing to ensure that the thing we reference will come out. I suspect, if we left that out, some things we'd want would not come out. __ NOD32 1.1419 (20060226) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
GCC port for V8-uRISC (8 bit CPU)
Hi, Can somebody please explain to me is it reasonable and possible to port gcc (version 4.xx) to 8 bit cpu architecture. I would appreciate precise explanation why it is possible or not. CPU is V8-uRISC. V8-uRISC Features are: 8-bit ALU 64K byte addressing capability Accumulator (R0) Seven 8-bit General Purpose Registers (R1-R7) Multiple register banks are easily implemented 16-bit Program Counter and Stack Pointer Thanks in advance for all informations. Regards, Nemanja Popov
Re: GCC port for V8-uRISC (8 bit CPU)
Thank you all for informations. Regards, Nemanja - Original Message - From: "Dave Hudson" <[EMAIL PROTECTED]> To: "Alan Lehotsky" <[EMAIL PROTECTED]>; "Nemanja Popov" <[EMAIL PROTECTED]>; Sent: Wednesday, April 05, 2006 7:21 PM Subject: RE: GCC port for V8-uRISC (8 bit CPU) FWIW we did get really great code generation for the IP2k in the end although it took some rather unpleasant machine-dependent-reorg stuff to work around the fact almost every instruction used a singe 8-bit accumulator registerr :-) Other ports to look at would be the AVR (8-bit RISC with 32 registers) and 68HC11 (more traditional accumulator-style 8-bit CPU). The AVR is a pretty nice clean port. Regards, Dave * -Original Message- * From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On * Behalf Of Alan Lehotsky * Sent: 05 April 2006 17:49 * To: Nemanja Popov; gcc@gcc.gnu.org * Subject: Re: GCC port for V8-uRISC (8 bit CPU) * * I participated in a port to an 8-bit internet toaster 4 years * ago (the Ubicom IP2k chip). * * It's distributed as part of the gcc-3.x releases, but has * been dropped from the gcc-4.x distributions. * * The IP2k was a very restrictive environment, and it took a * lot of work to get it to generate really tight code. * I'd definely suggest looking at gcc/config/ip2k to see how we * did it * * -Original Message- * >From: Nemanja Popov <[EMAIL PROTECTED]> * >Sent: Apr 5, 2006 9:50 AM * >To: gcc@gcc.gnu.org * >Subject: GCC port for V8-uRISC (8 bit CPU) * > * >Hi, * > * >Can somebody please explain to me is it reasonable and * possible to port * >gcc (version 4.xx) to 8 bit cpu architecture. * >I would appreciate precise explanation why it is possible or not. * > * >CPU is V8-uRISC. * > * >V8-uRISC Features are: * > * > 8-bit ALU * > 64K byte addressing capability * > Accumulator (R0) * > Seven 8-bit General Purpose Registers (R1-R7) Multiple register * > banks are easily implemented 16-bit Program Counter and * Stack Pointer * > * >Thanks in advance for all informations. * >Regards, * >Nemanja Popov * > * * * __ NOD32 1.1473 (20060405) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
dwarf2 compiling problem
Hi all. When compiling simple example (even c file with no code in it) with dlx-elf-gcc -c -gdwarf-2 foo.c I get the following error message: internal compiler error: in assemble_integer, at varasm.c:2148 I've defined debugging support in the following way: #define DBX_DEBUGGING_INFO 1 #define DBX_REGISTER_NUMBER(REGNO) (REGNO) #define DWARF2_DEBUGGING_INFO 1 #define PREFERRED_DEBUGGING_TYPE DBX_DEBUG Compiling without debug info or with stab debug format (-g) is working ok gcc:version 4.02 target: DLX CPU (port in progress) Does anyone have an idea what can cause this? Is this a bug in gcc or in target cpu files? Thanks, Nemanja
