Re: Bad Register Number for libgcc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 10.03.2013 18:05, schrieb Ian Lance Taylor:
> 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
>
Well it's a start I would say.
REG_CLASS_CONTENTS is a bitmask to specify with regno is in which class.
With that in mind :
#define REG_CLASS_CONTENTS  \
{  \
{0x00000000},   \
{0xB8FFFFFC},   \
{0xFFFFFFFF}    \
}
There are some registers that shouldn't be used by GCC so they are not
in GENERAL_REGS.

Maybe I will find a testcase to reproduce this problem.


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux