This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
[ Reported to the Debian BTS as report #89949. Please CC 89949-quiet@bugs.debian.org on replies. Log of report can be found at http://bugs.debian.org/89949 ] gcc generates non-intuitive code when one tries to increment a volatile int. extern int x; extern volatile int y; void f() { x++; y++; } The move into %eax seems pointless. ----------------------------------- gcc-3.0 and gcc CVS HEAD 20010701: .file "bug-89949.i" .text .align 2 .globl f .type f,@function f: pushl %ebp movl %esp, %ebp incl x movl y, %eax incl %eax movl %eax, y popl %ebp ret .Lfe1: .size f,.Lfe1-f .ident "GCC: (GNU) 3.1 20010701 (experimental)" ----------------------------------- gcc-3.0 and gcc CVS HEAD 20010701 -O2: .file "bug-89949.i" .text .align 2 .p2align 2,,3 .globl f .type f,@function f: pushl %ebp movl y, %eax movl %esp, %ebp incl %eax incl x popl %ebp movl %eax, y ret .Lfe1: .size f,.Lfe1-f .ident "GCC: (GNU) 3.1 20010701 (experimental)" ----------------------------------- Release: 3.0 (Debian GNU/Linux) and HEAD 20010701 Environment: System: Debian GNU/Linux (testing/unstable) Architecture: i686 host: i386-linux build: i386-linux target: i386-linux configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
State-Changed-From-To: open->closed State-Changed-Why: GCC doesn't know what constitutes a reference to a volatile memory, so it never performs operations on them directly. It will always pull the value into a register first.
From: Richard Henderson <rth@redhat.com> To: Herbert Xu <herbert@gondor.apana.org.au> Cc: rth@gcc.gnu.org, 89949-quiet@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: target/3506: weird behaviour when incrementing volatile ints Date: Wed, 3 Apr 2002 02:47:18 -0800 On Wed, Apr 03, 2002 at 08:29:27PM +1000, Herbert Xu wrote: > This breaks C99 wrt sig_atomic_t. The increment has to be a single > instruction. Um, no, *assignment* has to be a single instruction. Very different. r~
From: Herbert Xu <herbert@gondor.apana.org.au> To: rth@gcc.gnu.org, 89949-quiet@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: target/3506: weird behaviour when incrementing volatile ints Date: Wed, 3 Apr 2002 20:29:27 +1000 On Fri, Mar 29, 2002 at 10:42:35AM -0000, rth@gcc.gnu.org wrote: > Synopsis: weird behaviour when incrementing volatile ints > > State-Changed-From-To: open->closed > State-Changed-By: rth > State-Changed-When: Fri Mar 29 02:42:35 2002 > State-Changed-Why: > GCC doesn't know what constitutes a reference to a volatile memory, > so it never performs operations on them directly. It will always > pull the value into a register first. This breaks C99 wrt sig_atomic_t. The increment has to be a single instruction. -- Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reopen to ...
Mark as invalid.
*** Bug 21580 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Mark as invalid. Why?
(In reply to comment #7) > (In reply to comment #5) > > Mark as invalid. > > Why? Did you read comment #1.
(In reply to comment #8) > Did you read comment #1. Yes, but it's not clear. > GCC doesn't know what constitutes a reference to a volatile memory Is this to say the GCC developers believe the C language's definition of "volatile" is ambiguous, or that there are situations where "incl x" is operationally distinct from "movl x, %eax; incl %eax; movl %eax, x" when x is volatile?
*** Bug 33102 has been marked as a duplicate of this bug. ***