Bad Register Number for libgcc

Bad Register Number for libgcc

[Jens Mehler]

Hello,

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.

With best Regards
Jens

Re: Bad Register Number for libgcc

[Ian Lance Taylor]

On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> 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

Re: Bad Register Number for libgcc

[Jens Mehler]

Am 10.03.2013 17:51, schrieb Ian Lance Taylor:
> On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> 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'll do that and see what happens.
Thanks for the reply :)

~ Jens

Re: Bad Register Number for libgcc

[Ian Lance Taylor]

On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> wrote:
> Am 10.03.2013 17:51, schrieb Ian Lance Taylor:
>> On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> 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

Re: Bad Register Number for libgcc

[Jens Mehler]

Am 10.03.2013 18:05, schrieb Ian Lance Taylor:
> On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> wrote:
>> Am 10.03.2013 17:51, schrieb Ian Lance Taylor:
>>> On 3/10/13, Jens Mehler <jens.mehler@mni.thm.de> 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.

Re: Bad Register Number for libgcc

[Jens Mehler]

I may have found the problem:

the line:
gcc_assert(…) is converted to a branch instruction, which didn't have
any constraints at all.
After polishing up the machine instruction I got around this error.

After that another error has surfaced but this is because I didn't take
everything into account.
Thanks a lot for your help!

~Jens

Re: Bad Register Number for libgcc

[Chung-Ju Wu]

2013/3/11 Jens Mehler <jens.mehler@mni.thm.de>:
> Am 10.03.2013 18:05, schrieb Ian Lance Taylor:
> 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.

Hi, Jens,

Glad to see you found the problem in your latest mail.

However, since I am also working on a new 32-bit target port,
I would like to share my little experience that you may omit
when designing register classes.

As the number of your register classes grows up,
you probably have the chance to design a class x contained in another class y.
In that case, remember to order x has lower class number than y. :-)

See more information in:
http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html


Best regards,
jasonwucj

Re: Bad Register Number for libgcc

[Jens Mehler]

Am 16.03.2013 07:48, schrieb Chung-Ju Wu:
> 2013/3/11 Jens Mehler <jens.mehler@mni.thm.de>:
>> Am 10.03.2013 18:05, schrieb Ian Lance Taylor:
>> 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.
> Hi, Jens,
>
> Glad to see you found the problem in your latest mail.
>
> However, since I am also working on a new 32-bit target port,
> I would like to share my little experience that you may omit
> when designing register classes.
>
> As the number of your register classes grows up,
> you probably have the chance to design a class x contained in another class y.
> In that case, remember to order x has lower class number than y. :-)
>
> See more information in:
> http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html
>
>
> Best regards,
> jasonwucj
>
Hi jasonwucj,

Thanks for the advice. I studied the documentation about Register
Classes and am quite happy with the outcome of my port.
Until now I didn't discover any problems with the emitted assembler text.
As you can see in the definition above I have certainly applied that rule.
I hope you enjoy writing a new GCC backend as much as I did.
~ Jens