public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call
@ 2006-03-10 18:16 rmansfield at qnx dot com
2006-03-10 18:23 ` [Bug target/26636] " rmansfield at qnx dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: rmansfield at qnx dot com @ 2006-03-10 18:16 UTC (permalink / raw)
To: gcc-bugs
[rmansfield@bender rmansfield]$
/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/bin/sh4-unknown-linux-gnu-gcc
-v -o t.s -S -m4 -O2 t.c
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with:
/home/rmansfield/crosstool-0.42/build/sh4-unknown-linux-gnu/gcc-4.0-20060309-glibc-2.3.6/gcc-4.0-20060309/configure
--target=sh4-unknown-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu
--with-multilib-list=m4,m4-nofpu
--with-headers=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/include
--with-local-prefix=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.0.3
mov.l .L66,r0
mov r11,r1
mov.w .L65,r12
add #64,r1 ; use here
mov r3,r8
mov #30,r13
jsr @r0 ; call to __sdivsi3_4
nop
sts fpul,r2
add #-124,r8
mov #120,r0
add r3,r12
mov.l r0,@(8,r14)
mov #31,r7
mov.l r2,@(56,r1) ; kaboom
...
.L66:
.long __sdivsi3_i4
Then in the plt stub r1 gets clobbered.
0x804041c <_sdivsi3_i4>: mov.l 0x8040424 <_sdivsi3_i4+8>,r1 !
0x80418a0
0x804041e <_sdivsi3_i4+2>: mov.l @r1,r1
0x8040420 <_sdivsi3_i4+4>: jmp @r1
/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/bin/sh4-unknown-linux-gnu-gcc
-v -o t.s -S -m4 -O2 t.c
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with:
/home/rmansfield/crosstool-0.42/build/sh4-unknown-linux-gnu/gcc-4.1.0-glibc-2.3.6/gcc-4.1.0/configure
--target=sh4-unknown-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu
--with-multilib-list=m4,m4-nofpu
--with-headers=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/include
--with-local-prefix=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.1.0
gcc 4.1 generates the following code:
mov.l .L57,r0
jsr @r0
nop
sts fpul,r4
.L8:
mov.w .L55,r8
mov r9,r1
mov.w .L56,r12
add #64,r1
add r10,r8
mov.l r4,@(56,r1)
...
.L57:
.long __sdivsi3_i4
I think this hasn't been previously observed because the .hidden directive in
lib1funcs.asm makes each shared library get its own private __sdivsi3_i4 that
it can call directly and no registers end up being clobbered. But shouldn't
(clobber (reg:SI R1_REG)) in
"divsi3" prevent the use of R1-R3 across the __sdivsi3 call?
--
Summary: use of r1-r3 across __sdivsi3_4 call
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-host_pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
@ 2006-03-10 18:23 ` rmansfield at qnx dot com
2006-03-15 16:20 ` rmansfield at qnx dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rmansfield at qnx dot com @ 2006-03-10 18:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rmansfield at qnx dot com 2006-03-10 18:23 -------
When attaching the test case, I experience a internal error with gcc bugzilla
which I reported to dberlin. I am going to attach the test case in a comment.
I attempted to reduce the test case, but it changed reg. allocation which made
reproducing it difficult.
#include <stdlib.h>
#include <stdio.h>
# define M 14
# define PIT_MIN 30
# define SS_AUDIO_SAMPLE_SIZE 2
int main(int argc, char *argv[]) {
int iMarkEvntDelayTime = 0;
int iSampleRate = 0;
int iBlockSize = 0;
int t_op;
int corr[19999];
int f_io4[19999];
int daten[19999];
t_op = wbe_ol_pitch_estimate( daten, corr, f_io4);
return EXIT_SUCCESS;
}
#define PIT_MIN 30
#define PIT_MAX 193
#define L_SUBFR_LB 60
#define DIM (3*L_SUBFR_LB)
#define OLPX_SHIFT 4
int
wbe_ol_pitch_estimate
(
short *x_i,
int *corr,
int *x_local
)
{
int temp, temp1;
int energy;
int denom;
int thresh, thresh2;
int *x_t1_ptr, *x_t2_ptr;
int *x_t_max;
int *x;
int i,index,p;
for (i=0; i < PIT_MIN; i++)
corr[i] = 0;
x = x_local;
for (i = -PIT_MAX; i < DIM; i++)
{
*(x++) = x_i[i]>>OLPX_SHIFT;
}
x = x_local+PIT_MAX;
x_t_max = x +DIM;
x_t1_ptr = x;
x_t2_ptr = x-PIT_MIN;
energy= 0;
temp = 0;
while( x_t1_ptr < x_t_max)
{
temp1 = (int)(*x_t2_ptr);
temp += (*x_t1_ptr) * temp1;
energy += temp1 * temp1;
x_t1_ptr++;
x_t2_ptr++;
}
denom = energy>>10;
if (denom <= 0) denom=1;
corr[PIT_MIN] = temp/denom;
index = PIT_MIN;
for( i=PIT_MIN+1; i<PIT_MAX; i++)
{
temp = 0;
x_t1_ptr = x;
x_t2_ptr = x-i;
while( x_t1_ptr < x_t_max)
{
temp += (*x_t1_ptr) * (*x_t2_ptr);
x_t1_ptr++;
x_t2_ptr++;
}
temp1 = (int)x[DIM-i];
temp1 *= temp1;
energy -= temp1;
temp1 = (int)x[-i];
temp1 *= temp1;
energy += temp1;
/* calculate the normalized correlation temp/energy */
denom = energy>>10;
if (denom <= 0) denom=1;
temp = temp/denom;
corr[i] = temp;
thresh = (temp>>2) + (temp>>1);
if( i<((index<<1)-5))
if( temp > corr[index] )
index = i;
if( i>=((index<<1)-5))
if( thresh > corr[index] )
index = i;
}
thresh2=(corr[index]>>1);
p = index/3;
for( i=p-5; i<p+5; i++)
{
if( thresh2 < corr[i] )
{
index = i;
thresh2=(corr[index]>>1);
}
}
return( index );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
2006-03-10 18:23 ` [Bug target/26636] " rmansfield at qnx dot com
@ 2006-03-15 16:20 ` rmansfield at qnx dot com
2007-05-09 23:05 ` kkojima at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rmansfield at qnx dot com @ 2006-03-15 16:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rmansfield at qnx dot com 2006-03-15 16:20 -------
I looked at the RTL generated to find what pass R1 was first introduced and it
was greg. It appears (I'm not certain since I'm still learning to read RTL) the
that no clobber happens for the divsi3_i4 insn.
Looking at sh.md, R1-R3 are clobbered in the define_expand for divsi3
(define_expand "divsi3"
[(set (match_dup 3) (symbol_ref:SI "__sdivsi3"))
(set (reg:SI R4_REG) (match_operand:SI 1 "general_operand" ""))
(set (reg:SI R5_REG) (match_operand:SI 2 "general_operand" ""))
(parallel [(set (match_operand:SI 0 "register_operand" "")
(div:SI (reg:SI R4_REG)
(reg:SI R5_REG)))
(clobber (reg:SI T_REG))
(clobber (reg:SI PR_REG))
(clobber (reg:SI R1_REG))
(clobber (reg:SI R2_REG))
(clobber (reg:SI R3_REG))
(use (match_dup 3))])]
{
rtx first, last;
operands[3] = gen_reg_rtx (Pmode);
...
last = gen_divsi3_i4 (operands[0], operands[3]);
The define_insn for divsi3_i4 does not have the R1-R3 clobbers as they did in
2.95.3
(define_insn "divsi3_i4"
[(set (match_operand:SI 0 "register_operand" "=y")
(div:SI (reg:SI R4_REG) (reg:SI R5_REG)))
(clobber (reg:SI PR_REG))
(clobber (reg:DF DR0_REG))
(clobber (reg:DF DR2_REG))
(use (reg:PSI FPSCR_REG))
(use (match_operand:SI 1 "arith_reg_operand" "r"))]
"TARGET_SH4 && ! TARGET_FPU_SINGLE"
"jsr @%1%#"
[(set_attr "type" "sfunc")
(set_attr "fp_mode" "double")
(set_attr "needs_delay_slot" "yes")])
in 2.95.3:
(define_insn "divsi3_i4"
[(set (match_operand:SI 0 "register_operand" "=y")
(div:SI (reg:SI 4) (reg:SI 5)))
(clobber (reg:SI 18))
(clobber (reg:SI 17))
(clobber (reg:DF 24))
(clobber (reg:DF 26))
(clobber (reg:SI 0))
(clobber (reg:SI 1))
(clobber (reg:SI 2))
How is the clobber list for define_expand insn expected to work? Should it
clobber for all emitted rtl insns?
Adding:
(clobber (reg:SI R1_REG))
(clobber (reg:SI R2_REG))
(clobber (reg:SI R3_REG))
to the "divsi3_i4" insn gets around the problem, but is that the proper
solution?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
2006-03-10 18:23 ` [Bug target/26636] " rmansfield at qnx dot com
2006-03-15 16:20 ` rmansfield at qnx dot com
@ 2007-05-09 23:05 ` kkojima at gcc dot gnu dot org
2007-05-10 2:01 ` rmansfield at qnx dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2007-05-09 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-10 00:05 -------
__sdivsi3_i4 can't be called via PLT in the first place. This is
a design decision, I think. It is defined as a hidden symbol and
isn't exported from the shared libgcc with the right configuration.
All binaries and shared libraries which uses __sdivsi3_i4 should
link also with static libgcc.a to include it as a local function.
I'd like to close this PR as WONTFIX.
--
kkojima at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kkojima at gcc dot gnu dot
| |org
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
` (2 preceding siblings ...)
2007-05-09 23:05 ` kkojima at gcc dot gnu dot org
@ 2007-05-10 2:01 ` rmansfield at qnx dot com
2007-05-10 2:19 ` kkojima at gcc dot gnu dot org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rmansfield at qnx dot com @ 2007-05-10 2:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from rmansfield at qnx dot com 2007-05-10 03:01 -------
Thanks for looking at the PR. Has sdivsi3_i4 has always been hidden? I still
link against some shared libraries built with 2.95.3 where __sdivsi3_i4 is not
hidden. r1-r3 are in the clobber list for 2.95.3 so I don't trip if compile
with 2.95.3
For example:
$ readelf.exe -s libm.so | grep sdivsi3_i4
23: 0000a8b4 14 FUNC GLOBAL DEFAULT 9 __sdivsi3_i4
129: 0000a8b4 14 FUNC GLOBAL DEFAULT 9 __sdivsi3_i4
If I compile my program with gcc 3.4/4.x and the 2.95.3 libm.so appears before
the libgcc.a, a plt stub gets generated, r1 ends up gettng clobbered and the
program crashes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
` (3 preceding siblings ...)
2007-05-10 2:01 ` rmansfield at qnx dot com
@ 2007-05-10 2:19 ` kkojima at gcc dot gnu dot org
2007-05-10 3:55 ` rmansfield at qnx dot com
2007-05-10 4:25 ` kkojima at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2007-05-10 2:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from kkojima at gcc dot gnu dot org 2007-05-10 03:19 -------
Yes. 2.95.3 are broken about this and 2.95.3 libraries are ABI
incompatible with the newer binaries. That will never be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
` (4 preceding siblings ...)
2007-05-10 2:19 ` kkojima at gcc dot gnu dot org
@ 2007-05-10 3:55 ` rmansfield at qnx dot com
2007-05-10 4:25 ` kkojima at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: rmansfield at qnx dot com @ 2007-05-10 3:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rmansfield at qnx dot com 2007-05-10 04:55 -------
(In reply to comment #5)
> Yes. 2.95.3 are broken about this and 2.95.3 libraries are ABI
> incompatible with the newer binaries. That will never be fixed.
Okay, that's fine.
I also wasn't aware of the ABI change. Which release did the ABI breakage
happen? I took a quick look through changes.html for the major release and
nothing jumped out. Thanks for your help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/26636] use of r1-r3 across __sdivsi3_4 call
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
` (5 preceding siblings ...)
2007-05-10 3:55 ` rmansfield at qnx dot com
@ 2007-05-10 4:25 ` kkojima at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2007-05-10 4:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from kkojima at gcc dot gnu dot org 2007-05-10 05:24 -------
>From the patch
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01856.html
which was for 3.2, I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-05-10 4:25 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-10 18:16 [Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call rmansfield at qnx dot com
2006-03-10 18:23 ` [Bug target/26636] " rmansfield at qnx dot com
2006-03-15 16:20 ` rmansfield at qnx dot com
2007-05-09 23:05 ` kkojima at gcc dot gnu dot org
2007-05-10 2:01 ` rmansfield at qnx dot com
2007-05-10 2:19 ` kkojima at gcc dot gnu dot org
2007-05-10 3:55 ` rmansfield at qnx dot com
2007-05-10 4:25 ` kkojima at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).