On 3/10/13, Jens Mehler <jens.mehler@xxxxxxxxxx> wrote: > Am 10.03.2013 17:51, schrieb Ian Lance Taylor: >> On 3/10/13, Jens Mehler <jens.mehler@xxxxxxxxxx> wrote: >>> I have ported the GCC-4.5.3 for a 32-bit CPU. >>> Building GCC works like charm, even assembling several tests I wrote >>> myself works. >>> After porting the Gnu-Binutils I took my first approach of building >>> libgcc. >>> Poorly it runs into an error. >>> >>> ../../../gcc-4.5.3/libgcc/../gcc/libgcc2.c: In function '__powidf2': >>> ../../../gcc-4.5.3/libgcc/../gcc/libgcc2.c:1739:1: internal compiler >>> error: in use_type, at var-tracking.c:4903 >>> >>> On var-tracking.c line 4903: >>> gcc_assert (REGNO (loc) < FIRST_PSEUDO_REGISTER); >>> loc is an RTX. >>> >>> Can someone please give me pointer where the problem might be. >>> If additional information is I will provide them. >> Well, there is something wrong with your port. It's pretty hard to >> say what it is, though. The var tracking pass runs after the register >> allocation pass, which means that at that point in the compilation >> there should not be any pseudo-registers, only hard registers. >> Somehow you have a pseudo-register left. I don't know how. >> >> Ian >> > That's what I suspected but never actually got any proof of that. > From what I gathered while working on that: > Whenever I change my the mask for GENERAL_REGS in REG_CLASS_CONTENTS the > error is in a different function is libgcc. > Maybe I should really split out some regs and create another class for > them, because right now all registers GCC can use are in the same class > : GENERAL_REGS. I would not expect this problem to have anything to do with REG_CLASS_CONTENTS. REG_CLASS_CONTENTS only applies to hard registers. The issue here is that a pseudo-register was not converted to a hard register. Unless you have a REG_CLASS_CONTENTS that somehow permits pseudo-registers. That would be bad. Ian
