Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Christian Ehrhardt]

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

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: nejataydin@superonline.com, gcc-gnats@gcc.gnu.org, gcc@gcc.gnu.org,
  gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 13 Dec 2002 14:36:26 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7799
 
 Hi,
 
 this PR is about the following code snippet that is miscompiled with -Os
 
 void fill (int* p, int* q[10])
 {
         int i;
         for (i = 0; i < 10; i++)
                 *q++ = &p[i];
 }
 
 The asm-Code is this:
 
         pushl   %ebp
         movl    %esp, %ebp
         movl    8(%ebp), %eax
         movl    12(%ebp), %edx
         leal    36(%eax), %ecx
 .L6:
         movl    %eax, (%edx)
         addl    $4, %eax
         addl    $4, %edx
         cmpl    %ecx, %eax
         jle     .L6
         popl    %ebp
         ret
 
 This code roughly corresponds to the following C-Code:
 
 void fill (int * p, int *q[10])
 {
 	int ecx = (int)p + 9;
 	do {
 		*q = p; p++; q++;
 	} while ((int)p <= ecx);
 }
 
 This transformation is IMHO illegal because there is no way to make the
 comparison in general equivialent to that in the original for loop.
 If p is initially 0x7ffffffc the comparison must be treated as unsigned,
 however, if p is initially 0xfffffffc the comparison must be treated as
 signed.
 
     regards   Christian
 
 -- 
 THAT'S ALL FOLKS!

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Robert Dewar]

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

From: dewar@gnat.com (Robert Dewar)
To: amylaar@onetel.net.uk, segher@koffie.nl
Cc: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org, gcc@gcc.gnu.org, nejataydin@superonline.com
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 20 Dec 2002 19:25:45 -0500 (EST)

 > It can't wrap around there, but if pointers are signed, it might straddle 0
 > nonetheless.  This requires, of course, for an aligned start address
 > that the address 0 is not the same as NULL, which AFAICR is something gcc
 > doesn't currently support.
 
 Note that addresses *are* considered signed on the INMOS Transputer as a
 proof of existence :-)

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Christian Ehrhardt]

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

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Segher Boessenkool <segher@koffie.nl>
Cc: nejataydin@superonline.com, gcc-gnats@gcc.gnu.org, gcc@gcc.gnu.org,
  gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 20 Dec 2002 10:23:56 +0100

 On Thu, Dec 19, 2002 at 05:33:49PM +0100, Segher Boessenkool wrote:
 > > This transformation is IMHO illegal because there is no way to make the
 > > comparison in general equivialent to that in the original for loop.
 > > If p is initially 0x7ffffffc the comparison must be treated as unsigned,
 > > however, if p is initially 0xfffffffc the comparison must be treated as
 > > signed.
 > 
 > >From C99 final draft (I wish I had the final version of the standard):
 > > [ arrays can't wrap around address 0 ]
 
 Thanks. Others pointed this out as well.
 
 > The comparison should always be unsigned; I don't remember the x86 ISA well
 > enough to know if  jle  is unsigned, but I believe so.
 
 That's the point: jle is signed. jbe is unsigned. The signedness of the
 comparison is derived from the type of i which is wrong after elimination
 of the loop variable.
 
     regards   Christian
 
 -- 
 THAT'S ALL FOLKS!

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Joern Rennecke]

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

From: Joern Rennecke <amylaar@onetel.net.uk>
To: segher@koffie.nl (Segher Boessenkool)
Cc: ehrhardt@mathematik.uni-ulm.de (Christian Ehrhardt),
        nejataydin@superonline.com, gcc-gnats@gcc.gnu.org, gcc@gcc.gnu.org,
        gcc-bugs@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 20 Dec 2002 06:17:18 +0000 (GMT)

 > 6.2.5.19:
 >         ... An array type describes a contiguously allocated nonempty set of
 >         objects with a particular member object type, called the element
 >         type. ...
 >
 > So an array can not wrap around address 0.
 
 It can't wrap around there, but if pointers are signed, it might straddle 0
 nonetheless.  This requires, of course, for an aligned start address
 that the address 0 is not the same as NULL, which AFAICR is something gcc
 doesn't currently support.
 
 OTOH, if the start address is not aligned to a multiple of the types size,
 you can have the array straddle address 0 without it ever being a valid
 address.  Well, that is if character pointers have a different
 representation ;-)

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Segher Boessenkool]

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

From: Segher Boessenkool <segher@koffie.nl>
To: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>
Cc: nejataydin@superonline.com, gcc-gnats@gcc.gnu.org,
	gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization 
 flag -Os in gcc
Date: Thu, 19 Dec 2002 17:33:49 +0100

 Christian Ehrhardt wrote:
 > 
 > void fill (int* p, int* q[10])
 > {
 >         int i;
 >         for (i = 0; i < 10; i++)
 >                 *q++ = &p[i];
 > }
 > 
 > The asm-Code is this:
 > 
 >         pushl   %ebp
 >         movl    %esp, %ebp
 >         movl    8(%ebp), %eax
 >         movl    12(%ebp), %edx
 >         leal    36(%eax), %ecx
 > .L6:
 >         movl    %eax, (%edx)
 >         addl    $4, %eax
 >         addl    $4, %edx
 >         cmpl    %ecx, %eax
 >         jle     .L6
 >         popl    %ebp
 >         ret
 
 [SNIP]
 
 > This transformation is IMHO illegal because there is no way to make the
 > comparison in general equivialent to that in the original for loop.
 > If p is initially 0x7ffffffc the comparison must be treated as unsigned,
 > however, if p is initially 0xfffffffc the comparison must be treated as
 > signed.
 
 
 >From C99 final draft (I wish I had the final version of the standard):
 
 6.5.2.1.2
 
 	A postfix expression followed by an expression in square brackets []
 	is a subscripted designation of an element of an array object. ...
 
 So  p[i]  refers to an array element.
 
 
 6.2.5.19:
 	... An array type describes a contiguously allocated nonempty set of
 	objects with a particular member object type, called the element
 	type. ...
 
 So an array can not wrap around address 0.
 
 
 6.5.6.8
 
 	When an expression that has integer type is added to or subtracted from
 	a pointer, the result has the type of the pointer operand. ...
 
 	... If both the pointer operand and the result point to elements of the
 	same array object, or one past the last element of the array object, the
 	evaluation shall not produce an overflow; otherwise, the behavior is
 	undefined. ...
 
 So, if  p == 0xfffffffc  , the behaviour is undefined, as, for example,  &p[9]
 doesn't point to the same array as  p  .
 
 The comparison should always be unsigned; I don't remember the x86 ISA well
 enough to know if  jle  is unsigned, but I believe so.
 
 What am I missing / does C90 behave otherwise?
 
 
 Regards,
 
 Segher
 
 

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Eric Botcazou]

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Cc: nejataydin@superonline.com,
 gcc-gnats@gcc.gnu.org,
 gcc@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 13 Dec 2002 18:51:12 +0100

 > Thanks for the clarification. This means that we can close the report?
 
 'Suspended' is probably better.
 
 > I can confirm that using -fno-strength-reduce fixes the problem.
 
 The culprit is actually not the strength reduction pass per se, but the=20
 induction variable elimination pass that is bundled with it.
 
 --=20
 Eric Botcazou

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Christian Ehrhardt]

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

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: nejataydin@superonline.com, gcc-gnats@gcc.gnu.org, gcc@gcc.gnu.org,
  gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 13 Dec 2002 15:52:49 +0100

 On Fri, Dec 13, 2002 at 02:49:01PM +0100, Eric Botcazou wrote:
 > > This transformation is IMHO illegal because there is no way to make the
 > > comparison in general equivialent to that in the original for loop.
 > > If p is initially 0x7ffffffc the comparison must be treated as unsigned,
 > > however, if p is initially 0xfffffffc the comparison must be treated as
 > > signed.
 > 
 > Well-known deficiency of the strength reduction pass (see the testcase 
 > testsuite/gcc.c-torture/execute/loop-2e.c which is XFAILed on x86 at -Os).
 
 Thanks for the clarification. This means that we can close the report?
 I can confirm that using -fno-strength-reduce fixes the problem.
 
     regards  Christian
 
 -- 
 THAT'S ALL FOLKS!

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[Eric Botcazou]

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Cc: nejataydin@superonline.com,
 gcc-gnats@gcc.gnu.org,
 gcc@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org
Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc
Date: Fri, 13 Dec 2002 14:49:01 +0100

 > This transformation is IMHO illegal because there is no way to make the
 > comparison in general equivialent to that in the original for loop.
 > If p is initially 0x7ffffffc the comparison must be treated as unsigned=
 ,
 > however, if p is initially 0xfffffffc the comparison must be treated as
 > signed.
 
 Well-known deficiency of the strength reduction pass (see the testcase=20
 testsuite/gcc.c-torture/execute/loop-2e.c which is XFAILed on x86 at -Os)=
 =2E
 
 --=20
 Eric Botcazou

Re: optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

[bangerth]

Old Synopsis: Loop bug with optimization flag -Os in gcc
New Synopsis: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Fri Dec  6 12:52:32 2002
State-Changed-Why:
    Confirmed. Another regression. It works in 3.0.4, but not
    in 3.2 or 3.3.

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