public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2002-12-06 13:01 bangerth
  0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2002-12-06 13:01 UTC (permalink / raw)
  To: carlos, gcc-bugs, gcc-prs, nobody

Synopsis: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Fri Dec  6 13:01:29 2002
State-Changed-Why:
    Hm, the code goes into an endless loop on my system also
    without optimization and with all the compilers I have
    (i.e. gcc2.95, 3.0, 3.2, 3.2.2pre, 3.3pre, and icc7).
    Are you sure that the overflow you are exploiting is
    really defined in ISO C?

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2003-02-19 10:00 ebotcazou
  0 siblings, 0 replies; 6+ messages in thread
From: ebotcazou @ 2003-02-19 10:00 UTC (permalink / raw)
  To: carlos, gcc-bugs, gcc-prs, nobody

Synopsis: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete

State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Wed Feb 19 10:00:28 2003
State-Changed-Why:
    Already extensively analyzed.

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2002-12-06 13:28 bangerth
  0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2002-12-06 13:28 UTC (permalink / raw)
  To: carlos, gcc-bugs, gcc-prs, nobody

Synopsis: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete

State-Changed-From-To: feedback->open
State-Changed-By: bangerth
State-Changed-When: Fri Dec  6 13:28:26 2002
State-Changed-Why:
    Given the posted analyses, I don't think I can judge this one.

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2002-12-06 13:26 Carlos O'Donell
  0 siblings, 0 replies; 6+ messages in thread
From: Carlos O'Donell @ 2002-12-06 13:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
Date: Fri, 6 Dec 2002 16:23:05 -0500

 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Fri Dec  6 13:01:29 2002
 > State-Changed-Why:
 >     Hm, the code goes into an endless loop on my system also
 >     without optimization and with all the compilers I have
 >     (i.e. gcc2.95, 3.0, 3.2, 3.2.2pre, 3.3pre, and icc7).
 >     Are you sure that the overflow you are exploiting is
 >     really defined in ISO C?
 
 Unsigned overflow is defined. It is GCC's inconsistent
 implementation-dependant conversion that is causing the problem.
 
 "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." - Carlos
 
 c.
 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2002-12-06 13:26 Falk Hueffner
  0 siblings, 0 replies; 6+ messages in thread
From: Falk Hueffner @ 2002-12-06 13:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: <bangerth@dealii.org>, <carlos@baldric.uwo.ca>, <gcc-bugs@gcc.gnu.org>,
   <gcc-prs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: optimization/7726: Fails to produce the correct implementation-dependant
 output for loop optimization under x86 -> optimizes away a loop that should
 complete
Date: Fri, 6 Dec 2002 22:22:46 +0100 (CET)

 On 6 Dec 2002 bangerth@dealii.org wrote:
 
 > Hm, the code goes into an endless loop on my system also without
 > optimization and with all the compilers I have (i.e. gcc2.95, 3.0,
 > 3.2, 3.2.2pre, 3.3pre, and icc7). Are you sure that the overflow you
 > are exploiting is really defined in ISO C?
 
 Reading the value of a union member other than the last one stored into is
 undefined (at least in C99), so it could be easily argued that this is not
 a bug. However, gcc seems to support this in some other places (see the
 info entry about aliasing). So IMHO this should either be "fixed", or it
 should be documented exactly which union type punning tricks are OK.
 
 	Falk
 
 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete
@ 2002-08-26  9:46 carlos
  0 siblings, 0 replies; 6+ messages in thread
From: carlos @ 2002-08-26  9:46 UTC (permalink / raw)
  To: gcc-gnats


>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:


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-02-19 10:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-06 13:01 optimization/7726: Fails to produce the correct implementation-dependant output for loop optimization under x86 -> optimizes away a loop that should complete bangerth
  -- strict thread matches above, loose matches on Subject: below --
2003-02-19 10:00 ebotcazou
2002-12-06 13:28 bangerth
2002-12-06 13:26 Carlos O'Donell
2002-12-06 13:26 Falk Hueffner
2002-08-26  9:46 carlos

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).