[Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call

[Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call

[rmansfield at qnx dot com]

[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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[rmansfield at qnx dot com]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[rmansfield at qnx dot com]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[kkojima at gcc dot gnu dot org]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[rmansfield at qnx dot com]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[kkojima at gcc dot gnu dot org]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[rmansfield at qnx dot com]

------- 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

[Bug target/26636] use of r1-r3 across __sdivsi3_4 call

[kkojima at gcc dot gnu dot org]

------- 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