[Bug optimization/11753] New: %o7 register being used immediately in the delay slot before a call with -O2

[Bug optimization/11753] New: %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753

           Summary: %o7 register being used immediately in the delay slot
                    before a call with -O2
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: warren_baird at cimmetry dot com
                CC: gcc-bugs at gcc dot gnu dot org

gcc -v output:
Reading specs from /usr/local/gcc-3.2.2/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/usr/local/gcc-3.2.2
--with-gnu-as --with-gnu-ld --with-gnu-nm
--with-as=/usr/local/binutils-2.13.2.1/bin/as
--with-ld=/usr/local/binutils-2.13.2.1/bin/ld
--with-nm=/usr/local/binutils-2.13.2.1/bin/nm
Thread model: posix
gcc version 3.2.2


if you compile the attached .i file with -O2 optimization:

    gcc -c -O2 -S bug_o7.i

And you look around line 414 of the bug_o7.s file you should see code
like this:

	mov	1, %i0
	call	free, 0
	add	%o7, (.LL1-.-4), %o7


The problem here is that on a sparc system register %o7 is used to
pass the return address to a function, and since we're modifying it in
the delay slot, %o7 is modified just before the call to free, and when
free tries to return it jumps back to a different piece of code and
crashes almost immediately.

If I compile with -O1 it doesn't generate this construct.  Also, if I
try to remove almost any code from the function it doesn't generate
this construct.  It looks to me like it is only under fairly rare
circumstances that the optimizer produces this particular error.

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From warren_baird at cimmetry dot com  2003-07-31 18:53 -------
Created an attachment (id=4539)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4539&action=view)
preprocessed source to repro the bug

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Keywords|                            |wrong-code
         Resolution|                            |FIXED
   Target Milestone|3.4                         |---


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-31 19:05 -------
3.2.x is no longer being maintained.  With 3.3.1 (20030714) and the mainline 
(20030714) both do not produce code with using %o7 in the delay slot before a call.
Closing as fixed.

I would try 3.3 and see if that fixes your problem.  Also 3.3.1 is comming out in the next 
two weeks try that when it comes out.

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753


ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at physics dot uc
                   |                            |dot edu


------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-08-01 07:26 -------
Andrew,

Did you try with GCC 3.2.3? Is the problem still present?

I'm away from the SPARC boxes I hack GCC on so I can't help for the time being. 
But I'd like to investigate the problem anyway, so I'm going to reopen the PR 
and assign it to me.

Thanks for your great triaging work!

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753


ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-08-01 07:28 -------
I reopen it so that I can keep track of it.

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753


ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
           Severity|critical                    |minor
             Status|UNCONFIRMED                 |ASSIGNED
           Priority|P1                          |P3

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From warren_baird at cimmetry dot com  2003-08-01 13:28 -------
Subject: Re:  %o7 register being used immediately
	 in the delay slot before a call with -O2




Thanks for keeping an eye on this one, Eric...  As I said in the original
report, it seems to be very sensitive to many things --- my gut feeling is that
switching to gcc-3.3.1 'fixes' the problem in the same way that removing a few
lines from the function 'fixes' the problem...  The optimizer bug is still
there, just not showing up under these conditions any more...

Let me know if there's anything else I can do to help...

Warren

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-09-05 14:17 -------
It is my understanding that the optimization (which can be selectively disabled
by passing -fno-peephole to the compiler) is valid per se on SPARC:

with -fno-peephole:
	mov	1, %i0
	call	free, 0
	 nop
	b,a	.LL1

without -fno-peephole:
	mov	1, %i0
	call	free, 0
	add	%o7, (.LL1-.-4), %o7

Both codes call free() and jump to the .LL1 label. This is obvious for the
former and works for the latter as follows: the 'call' causes its address to be
copied into %o7 (via the PC) and executes the 'add' in the delay slot before
jumping to its target. The argument of the 'add' is basically '.LL1-.', which
means the difference between the address of .LL1 and the current address (that
of the 'add'). When added to the address of the 'add', this argument gives .LL1
so, when added to the address of the 'call' (which is in %o7), it gives .LL1-4.
With the final -4 correction, it gives .LL1-8. So %o7 hold .LL1-8 when the jump
is executed. Now, the return-from-subroutine insn on SPARC is 'ret', which is an
alias for

   jmp %i7+8

so the final return address is just .LL1, QED.

To help you convince yourself, you can compile the following little program

#include <stdio.h>

int main(int argc, char *argv[])
{
   if (argc > 1)
      printf("at least one argument\n");
   else
      printf("no argument\n");
   
   return 0;
}

with no optimization, manually turn in the assembly file

	call	printf, 0
	 nop
	b	.LL3
	 nop

into
        call    printf, 0
        add     %o7, (.LL3-.-4), %o7

and assemble. The program should work flawlessly.

Here's what I get when assembled with the Sun assembler:

        106a8:  40 00 40 66        call         printf
        106ac:  9e 03 e0 10        add          %o7, 16, %o7
        106b0:  11 00 00 41        sethi        %hi(0x10400), %o0
        106b4:  90 12 23 90        or           %o0, 0x390, %o0 ! 0x10790
        106b8:  40 00 40 62        call         printf
        106bc:  01 00 00 00        nop
        106c0:  90 10 20 00        clr          %o0

One big restriction is, of course, that the difference of addresses be
representable as an immediate operand (signed 13-bit field). With your testcase,
I get with the Sun assembler

	 59c:  40 00 00 00         call    	0x59c
	 5a0:  9e 03 ef 50         add     	%o7, 3920, %o7

3920 is a valid signed 13-bit operand. Moreover, doing the math:
   0x59c + 3920 + 8 = 0x14F4

and

	14f4:  01 00 00 00         nop     	
	14f8:  81 c7 e0 08         ret     	
	14fc:  81 e8 00 00         restore 	

is just 

.LL1:
	nop
	ret
	restore

So everything seems to be fine again.


Could you see why the optimization seems to be failing with your original code?
Where does the final return address point to?

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From warren_baird at cimmetry dot com  2003-09-05 22:10 -------
The problem seems to be that the wrong number is added to the %o7 register.  

Here is the code as it looks inside gdb:

    0xfb3437ac <MyFunc+1468>:	mov  1, %i0
    0xfb3437b0 <MyFunc+1472>:	call  0xfb3a415c <__JCR_LIST__+4900>
    0xfb3437b4 <MyFunc+1476>:	add  %o7, -3904, %o7
    0xfb3437b8 <MyFunc+1480>:	fcmped  %f6, %f8
    0xfb3437bc <MyFunc+1484>:	nop 


when we get back from the call to free, we end up at 0xfb342878 - which is in
the middle of some other function: 


(gdb) x/5i 0xfb3437b0 - 3904 +8
0xfb342878 <SomeOtherFunction+5644>:     nop 
0xfb34287c <SomeOtherFunction+5648>:     fbl,a   0xfb342774 <SomeOtherFunction+5384>
0xfb342880 <SomeOtherFunction+5652>:     fsubd  %f10, %f12, %f10
0xfb342884 <SomeOtherFunction+5656>:     b  0xfb341f98 <SomeOtherFunction+3372>
0xfb342888 <SomeOtherFunction+5660>:     sll  %l3, 1, %l6

And we crash almost immediately.   However, it looks like too large a value is
being written into the offset.  If we assume that -3904 was intended to be a
positive value (8192 - 3904), we see the code we expect to see.

(gdb) x/5i 0xfb3437b0 + 8192 - 3904 +8
0xfb344878 <MyFunc+5768>:	nop 
0xfb34487c <MyFunc+5772>:	ret 
0xfb344880 <MyFunc+5776>:	restore 
0xfb344884 <AnotherFunc>:	save  %sp, -128, %sp
0xfb344888 <AnotherFunc+4>:	clr  %i4

so it looks like the value that is being used is too large...  The question is
--- what can we do about it?  the preprocessed source I provided contains the
entire source code for the function in question.  Is that enough to figure out
why the optimization is being used, even though the value is too large?

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-09-06 11:38 -------
The optimization gets triggered because the compiler thinks that the target
address is within the range of an immediate operand, that is it internally
calculates the difference of addresses as being representable by a 13-bit signed
integer because it underestimates the size of several insns, in this case by

   8192 - 3904 - 4096 = 192 bytes

which represents 48 insns.

This suggests that the problem affects a widely-used insn or a group of insns.
I've identified such a problem and attached a patch (against the 3.2.x branch)
that cures it. Could you try it with your original testcase?

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From warren_baird at cimmetry dot com  2003-09-08 22:26 -------
I've tried the fix, and it does seem to solve the problem - at least it no
longer tries to use the optimziation in the same place.  

Thanks very much for your help!

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-09-10 14:37 -------
After thinking a bit more about it, I think that my first patch contains a fair
amount of useless cruft. So I've attached a second version. Could you try it
against your original testcase too? If it passes the test, I'll request approval
for merging it in the upcoming 3.3.2 release. Thanks in advance.

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From warren_baird at cimmetry dot com  2003-09-17 15:29 -------
Sorry it took so long --- I finally got around to testing the second fix, and it
seems to work fine...

Thanks!

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[cvs-commit at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-10-01 06:08 -------
Subject: Bug 11753

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	ebotcazou@gcc.gnu.org	2003-10-01 06:08:40

Modified files:
	gcc            : ChangeLog 
	gcc/config/sparc: sparc.md 

Log message:
	PR optimization/11753
	* config/sparc/sparc.md (length attribute) [fcc branch]: Add 1 to
	the length in the non-V9 case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1235&r2=2.1236
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gcc&r1=1.191&r2=1.192

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[cvs-commit at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-10-01 06:15 -------
Subject: Bug 11753

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	ebotcazou@gcc.gnu.org	2003-10-01 06:15:03

Modified files:
	gcc            : ChangeLog 
	gcc/config/sparc: sparc.md 

Log message:
	PR optimization/11753
	* config/sparc/sparc.md (length attribute) [fcc branch]: Add 1 to
	the length in the non-V9 case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.756&r2=1.16114.2.757
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.181.4.7&r2=1.181.4.8

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-01 06:20 -------
Fixed in 3.3 and the mainline.

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753



------- Additional Comments From ebotcazou at gcc dot gnu dot org  2003-10-01 06:23 -------
See http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00808.html

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[dhazeghi at yahoo dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753

[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[ebotcazou at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.3                       |3.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11753