public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: carlos@baldric.uwo.ca
To: gcc-gnats@gcc.gnu.org
Subject: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
Date: Mon, 26 Aug 2002 09:46:00 -0000	[thread overview]
Message-ID: <20020826152952.23841.qmail@sources.redhat.com> (raw)


>Number:         7726
>Category:       optimization
>Synopsis:       Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 26 08:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Carlos O'Donell
>Release:        gcc version 2.95.4 20011002 (Debian prerelease),  gcc version 3.0.4, gcc version 3.1.1 20020703 (Debian prerelease)
>Organization:
>Environment:
gcc       2.95.4-16         The GNU C compiler.
gcc-3.0   3.0.4-10          The GNU C compiler.
gcc-3.1   3.1.1-0pre3       The GNU C compiler.
libc6     2.2.5-7           GNU C Library
binutils  2.12.90.0.9-1     GNU Binutils
(Slightly modified dpkg -l output)
>Description:
Fails to produce the correct implementation-dependant output.

The compiler optimizes away the while loop that would 
eventually exit.

With 'gcc -O9 -o test test.c'
On the following compilers:

Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,objc --prefix=/usr --
infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-s
ystem-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --e
nable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-
linux
Thread model: posix
gcc version 3.0.4

Reading specs from /usr/lib/gcc-lib/i386-linux/3.1.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.1-3.1.1ds2/src/configure -v --enable-languages=c,c+
+,java,f77,proto,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --
with-gxx-include-dir=/usr/include/g++-v3-3.1 --enable-shared --with-system-zlib --enable-lon
g-long --enable-nls --without-included-gettext --enable-clocale=gnu --enable-__cxa_atexit --
enable-threads=posix --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.1.1 20020703 (Debian prerelease)

---
union sconvert {
        unsigned int uval;
        signed int sval;
};

int main()
{
        union sconvert i = { 0 };
        union sconvert oldi = { 0 };

        i.uval++;
        while (i.sval > oldi.sval) {
                oldi = i;
                i.uval++;
        }
        return oldi.sval;
}
---

Signed overflow is undefined in ANSI C, but this
particular example uses defined unsigned overflow to
carry out the addition.

The comparison is between to signed values that gcc
must convert. This conversion is implementation-dependant.
As such, the implementation-dependant behaviour cannot
be optimized away and must remain consistent across 
optimization levels.

This bug is a correction/refinement of a previous bug that 
incorrectly assumed signed overflow to be defined.
>How-To-Repeat:
Insert the code in 'Description' -> test.c
$ gcc -O9 -o test test.c
$ ./test
This will run forever since the exit case for the loop
has been optimized away.
>Fix:
Workaround: 
Don't use -ON (N>0)
or
Use and 'asm' statement as an optimization barrier.
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2002-08-26 15:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-26  9:46 carlos [this message]
2002-12-06 13:01 bangerth
2002-12-06 13:26 Falk Hueffner
2002-12-06 13:26 Carlos O'Donell
2002-12-06 13:28 bangerth
2003-02-19 10:00 ebotcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020826152952.23841.qmail@sources.redhat.com \
    --to=carlos@baldric.uwo.ca \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).