This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: target/3920: wrong register number for CTR in stabs
- From: "Mattias Engdegård" <mattias at virtutech dot se>
- To: geoffk at redhat dot com
- Cc: rth at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, geoffk at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Mon, 24 Jun 2002 12:02:53 +0200
- Subject: Re: target/3920: wrong register number for CTR in stabs
- References: <20020620235429.21173.qmail@sources.redhat.com> <200206210530.g5L5Ub513976@desire.geoffk.org>
>Why do you think this is incorrect? The assembler code generated by
>GCC 3.1 with -O2 -g -mregnames is:
[...]
>.L9:
> add %r0,%r0,%r3
> addi %r3,%r3,-1
> bdnz .L9
You are right of course. Gcc 2.95 didn't use an integer register that
worked in parallel with CTR and would instead do a mfctr in the loop
(which is less efficient of course), so I was confused in my reporting.
Sorry about that.
A better example would be
int sum(int n)
{
int i, j = 0, s = 0;
for(i = n; i != 0; i--) {
s += j;
j *= 2;
}
return s;
}
the loop of which gcc 3.0.2 (I didn't have 3.1 handy) turns into the nice code
.L8:
add %r3,%r3,%r0
slwi %r0,%r0,1
bdnz .L8
but where the stabs claim 'i' lives in register 66, which does not make sense
for CTR. The DWARF2 output (compiling with -gdwarf-2) seems to use the same
incorrect numbering.
I will check 3.1 as soon as I have built it.