Re: optimization/6673: gcc-3.1 produces wrong assembly code

Re: optimization/6673: gcc-3.1 produces wrong assembly code

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Nam SungHyun <namsh@wimo.co.kr>, rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, namsh@kldp.org, nobody@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/6673: gcc-3.1 produces wrong assembly code
Date: Thu, 16 May 2002 22:02:00 -0700

 On Fri, May 17, 2002 at 01:53:24PM +0900, Nam SungHyun wrote:
 > I saw the feed back message from the gnats web, but did not get a
 > mail. Did not know how I can reply for that feedback.
 
 The gnats bug form has an originator email address that
 it cc's all status changes on.  Did you mistype it?
 
 >     the 'a' in my example source is a 'global variable'.
 >     So, should the gcc treat it as a volatile by default?
 
 No.
 
 >     There are so many multi-threaded program. I didn't see
 >     any program which use volatile for the global variable.
 
 Nor does any C compiler produce "thread aware" code by default.
 
 You have to use cpu-specific thread synchronization primitives
 in order for that to work reliably.  Such a primitive would as
 a side effect tell the compiler that data must be committed to
 memory, which would cause 'a' to be written.
 
 You did none of these.
 
 
 r~

Re: optimization/6673: gcc-3.1 produces wrong assembly code

[Nam SungHyun]

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

From: Nam SungHyun <namsh@wimo.co.kr>
To: Richard Henderson <rth@redhat.com>, rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, namsh@kldp.org, nobody@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/6673: gcc-3.1 produces wrong assembly code
Date: Fri, 17 May 2002 14:24:42 +0900

 Richard Henderson wrote:
 > On Fri, May 17, 2002 at 01:53:24PM +0900, Nam SungHyun wrote:
 > > I saw the feed back message from the gnats web, but did not get a
 > > mail. Did not know how I can reply for that feedback.
 > 
 > The gnats bug form has an originator email address that
 > it cc's all status changes on.  Did you mistype it?
 
 I typed namsh@kldp.org and it's valid. ???
 
 > >     the 'a' in my example source is a 'global variable'.
 > >     So, should the gcc treat it as a volatile by default?
 > 
 > No.
 > 
 > >     There are so many multi-threaded program. I didn't see
 > >     any program which use volatile for the global variable.
 > 
 > Nor does any C compiler produce "thread aware" code by default.
 > 
 > You have to use cpu-specific thread synchronization primitives
 > in order for that to work reliably.  Such a primitive would as
 > a side effect tell the compiler that data must be committed to
 > memory, which would cause 'a' to be written.
 > 
 > You did none of these.
 
 You mean I should use '-fvolatile-global -fvolatile-static'?
 Now I compiled the example source with:
 
     ppc-eabi-gcc -O1 -fvolatile-global -fvolatile-static -S ex.c
 
 The result is same. What's wrong?
 
 Regards,
 namsh
 
 	.file	"ex.c"
 	.globl __eabi
 	.section	".text"
 	.align 2
 	.globl main
 	.type	main,@function
 main:
 	stwu 1,-8(1)
 	mflr 0
 	stw 0,12(1)
 	bl __eabi
 .L2:
 	b .L2
 .Lfe1:
 	.size	main,.Lfe1-main
 	.comm	a,4,4
 	.ident	"GCC: (GNU) 3.1"

Re: optimization/6673: gcc-3.1 produces wrong assembly code

[Nam SungHyun]

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

From: Nam SungHyun <namsh@wimo.co.kr>
To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, namsh@kldp.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/6673: gcc-3.1 produces wrong assembly code
Date: Fri, 17 May 2002 13:53:24 +0900

 rth@gcc.gnu.org wrote:
 > Synopsis: gcc-3.1 produces wrong assembly code
 > 
 > State-Changed-From-To: feedback->closed
 > State-Changed-By: rth
 > State-Changed-When: Thu May 16 19:12:57 2002
 > State-Changed-Why:
 >     As diagnosed, not a bug.
 
 I saw the feed back message from the gnats web, but did not get a
 mail. Did not know how I can reply for that feedback.
 
 I just wanted to be sure:
 
     the 'a' in my example source is a 'global variable'.
     So, should the gcc treat it as a volatile by default?
     There are so many multi-threaded program. I didn't see
     any program which use volatile for the global variable.
 
 Regards,
 
 namsh

Re: optimization/6673: gcc-3.1 produces wrong assembly code

[rth]

Synopsis: gcc-3.1 produces wrong assembly code

State-Changed-From-To: feedback->closed
State-Changed-By: rth
State-Changed-When: Thu May 16 19:12:57 2002
State-Changed-Why:
    As diagnosed, not a bug.

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

Re: optimization/6673: gcc-3.1 produces wrong assembly code

[jakub]

Synopsis: gcc-3.1 produces wrong assembly code

State-Changed-From-To: open->feedback
State-Changed-By: jakub
State-Changed-When: Thu May 16 06:40:11 2002
State-Changed-Why:
    Why do you think this is wrong?
    If there is no volatile, there is nothing which prevents
    gcc e.g. with ++a; ++a; ++a to do all the additions at
    once and store just the final result. Similarly with your
    testcase, gcc does all additions together and stores the
    end result after all infinity iterations. Since the loop
    will never finish, gcc can as well optimize the final
    store out.

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

optimization/6673: gcc-3.1 produces wrong assembly code

[namsh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]


>Number:         6673
>Category:       optimization
>Synopsis:       gcc-3.1 produces wrong assembly code
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Thu May 16 03:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Nam SungHyun
>Release:        3.1
>Organization:
>Environment:
System: Linux namsh 2.4.19-pre8 #3 ±Ý 5¿ù 3 11:33:25 KST 2002 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: powerpc-unknown-eabi
configured with: ./configure --disable-nls --target=ppc-eabi --prefix=/usr/GNUPPC --with-gnu-ld --with-gnu-as --program-prefix=ppc-eabi-
>Description:
	I build powerpc-unknown-eabi cross compiler using gcc
	CVS tree (cvs co -r gcc_3_1_release).

	input source (ex.c) is:
	============================================================ 
	    unsigned long a;
	    int
	    main(void)
	    {
		for (;;)
		    ++a;
	    }
	============================================================ 

	'ppc-eabi-gcc -O1 -S ex.c' generates:
	============================================================ 
		    .file	"ex.c"
		    .globl __eabi
		    .section	".text"
		    .align 2
		    .globl main
		    .type	main,@function
	    main:
		    stwu 1,-8(1)
		    mflr 0
		    stw 0,12(1)
		    bl __eabi
	    .L2:
		    b .L2
	    .Lfe1:
		    .size	main,.Lfe1-main
		    .comm	a,4,4
		    .ident	"GCC: (GNU) 3.1"
	============================================================ 

	There's no asm code for '++a'.
	ppc-eabi-gcc 2.95.4 20010319 (prerelease) works as I expected.

>How-To-Repeat:
	Always...
	preprocessor output is same as input source. so simple source

>Fix:
	1. use 'volatile' for 'a':     volatile unsigned long a;
	2. use '-O0' compile option

>Release-Note:
>Audit-Trail:
>Unformatted: