optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

[wilhelm.nuesser]

>Number:         4186
>Category:       optimization
>Synopsis:       core dump in -O2 on ia32 with attached code (regression to 2.95.*)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 31 07:36:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     wilhelm.nuesser@sap.com
>Release:        gcc version 3.0.1
>Organization:
>Environment:

Linux ia32, glibc 2.1, SuSE 7.0, RH 6.* ...
gcc -v gives:
Reading specs from /opt/gcc301/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs
Configured with: ../gcc/gcc-3.0.1/configure --prefix=/opt/gcc301 --enable-shared
Thread model: single
gcc version 3.0.1
>Description:
Attached code gives core dumps when compiling with -O2.
Running -O1 works. Changing the struct s1 (removing an 
unused short) also works. Changing third parameter of memcpy
to int constant also works. 
>How-To-Repeat:
Compile attached code with -O2
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="testc.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="testc.c"

I2luY2x1ZGUgPHN0cmluZy5oPgoKCnR5cGVkZWYgc3RydWN0IHMxIAp7CiAgICB1bnNpZ25lZCBj
aGFyICAqIGVudHJ5X3A7ICAgICAKICAgIHNob3J0ICAgICAgICAgICAgZW50cnlfbnI7ICAgIAog
ICAgc2hvcnQgICAgICAgICAgICBlbnRyeWxnOyAgCiAgICBzaG9ydCAgICAgICAgICAgIGxsZW47
ICAgICAKfQpzMTsKCgpzdGF0aWMgdm9pZCBmMSAodm9pZCAqIHRhYmRpciwgdW5zaWduZWQgY2hh
ciAqIGNvbnN0IGtleXMsCgkJCQkgIGNvbnN0IHMxICBlbnRyeV9sb2MpCnsKICBpbnQga2V5bGcg
PSAxMTsKCiAgKHZvaWQpIG1lbWNweShrZXlzLCBlbnRyeV9sb2MuZW50cnlfcCwga2V5bGcpOwp9
CgoKaW50IG1haW4oKQp7CiAgdm9pZCAgICAgICAgICAgICAgICAgICogdGFiZGlyOwogIHVuc2ln
bmVkIGNoYXIgICAgICAgICAqIGtleXM7CiAgczEgICAgICAgICAgICAgICAgICAgICAgZW50cnlf
bG9jOwoKICAvKiBidWlsZCB1cCAqLwogIGtleXMgPSAodW5zaWduZWQgY2hhciopIG1hbGxvYygx
MSk7CiAKICBlbnRyeV9sb2MuZW50cnlfcCA9ICh1bnNpZ25lZCBjaGFyICopIG1hbGxvYygxMSk7
CiAgbWVtc2V0KGVudHJ5X2xvYy5lbnRyeV9wLCAnQScsIDExKTsKCiAgZjEodGFiZGlyLCBrZXlz
LCBlbnRyeV9sb2MpOyAKICAKICByZXR1cm4gKDApOwp9Cg==

Re: optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

[rodrigc]

The following reply was made to PR optimization/4186; it has been noted by GNATS.

From: rodrigc@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nobody@gcc.gnu.org, thomas.hiller@compaq.com, wilhelm.nuesser@sap.com
Cc:  
Subject: Re: optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)
Date: 12 Dec 2001 05:38:12 -0000

 Synopsis: core dump in -O2 on ia32 with attached code (regression to 2.95.*)
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: rodrigc
 State-Changed-When: Tue Dec 11 21:38:12 2001
 State-Changed-Why:
     This looks like it is fixed in gcc 3.0.2
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4186&database=gcc

Re: optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

[rodrigc]

Synopsis: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

State-Changed-From-To: analyzed->closed
State-Changed-By: rodrigc
State-Changed-When: Tue Dec 11 21:38:12 2001
State-Changed-Why:
    This looks like it is fixed in gcc 3.0.2

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4186&database=gcc

Re: optimization/4186: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

[wilson]

Synopsis: core dump in -O2 on ia32 with attached code (regression to 2.95.*)

State-Changed-From-To: open->analyzed
State-Changed-By: wilson
State-Changed-When: Mon Sep 24 12:45:55 2001
State-Changed-Why:
    This is a sibling call optimization bug.  This can be
    worked around by using -fno-optimize-sibling-calls.
    
    Note the assembly code for function f1:
    f1:
    	pushl	%ebp
    	movl	%esp, %ebp
    	subl	$24, %esp
    	movl	$11, 16(%ebp)
    	movl	12(%ebp), %eax
    	movl	%eax, 8(%ebp)
    	movl	16(%ebp), %eax
    	movl	%eax, 12(%ebp)
    	movl	%ebp, %esp
    	popl	%ebp
    	jmp	memcpy
    When we store the constant 11 on the stack, we accidentally
    overwrite the second incoming argument (keys) before we
    read it, and thus we pass 11 as the firt and third arguments
    to memcpy, which causes memcpy to segfault, since 11 is
    not a valid address.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4186&database=gcc