[Bug c++/22129] New: Optimization stomps const, initialized local array

[Bug c++/22129] New: Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

I've found a case where it appears that the optimizer has reordered some code
surrounding the initialization of a local constant array, stomping on some of
the elements after they have been loaded with the correct values. Here's a
snippet of the source and resulting assembly that illustrates the problem (these
are pulled from the complete source which is attached):

// C++
586:	{
587:		const byte encrypted[] = {	// from Eric Young's libdes
588:			0xf3,0x09,0x62,0x49,0xc7,0xf4,0x6e,0x51,
589:			0x35,0xf2,0x4a,0x24,0x2e,0xeb,0x3d,0x3f,
590:			0x3d,0x6d,0x5b,0xe3,0x25,0x5a,0xf8,0xc3};
                ...
         }

// ASM
//
// It appears that the local array "encrypted" is at offset 0xffffff08 from
// %ebp. We dutifully load the first byte (0xf3) and then do some other stuff
// apparently using that same location for scratch and then proceed with
// the rest of the array initialization
//
    2cab:       c6 85 08 ff ff ff f3    movb   $0xf3,0xffffff08(%ebp)
    2cb2:       ba 08 00 00 00          mov    $0x8,%edx
    2cb7:       b9 08 00 00 00          mov    $0x8,%ecx
    2cbc:       89 95 08 ff ff ff       mov    %edx,0xffffff08(%ebp)
    2cc2:       31 c0                   xor    %eax,%eax
    2cc4:       8d 55 b8                lea    0xffffffb8(%ebp),%edx
    2cc7:       89 8d 28 ff ff ff       mov    %ecx,0xffffff28(%ebp)
    2ccd:       8d 8d 30 ff ff ff       lea    0xffffff30(%ebp),%ecx
    2cd3:       c6 85 09 ff ff ff 09    movb   $0x9,0xffffff09(%ebp)
    2cda:       c6 85 0a ff ff ff 62    movb   $0x62,0xffffff0a(%ebp)
    2ce1:       c6 85 0b ff ff ff 49    movb   $0x49,0xffffff0b(%ebp)
    2ce8:       c6 85 0c ff ff ff c7    movb   $0xc7,0xffffff0c(%ebp)
    2cef:       c6 85 0d ff ff ff f4    movb   $0xf4,0xffffff0d(%ebp)
    2cf6:       c6 85 0e ff ff ff 6e    movb   $0x6e,0xffffff0e(%ebp)
    2cfd:       c6 85 0f ff ff ff 51    movb   $0x51,0xffffff0f(%ebp)
    2d04:       c6 85 10 ff ff ff 35    movb   $0x35,0xffffff10(%ebp)
    2d0b:       c6 85 11 ff ff ff f2    movb   $0xf2,0xffffff11(%ebp)
    2d12:       c6 85 12 ff ff ff 4a    movb   $0x4a,0xffffff12(%ebp)
    2d19:       c6 85 13 ff ff ff 24    movb   $0x24,0xffffff13(%ebp)
    2d20:       c6 85 14 ff ff ff 2e    movb   $0x2e,0xffffff14(%ebp)
    2d27:       c6 85 15 ff ff ff eb    movb   $0xeb,0xffffff15(%ebp)
    2d2e:       c6 85 16 ff ff ff 3d    movb   $0x3d,0xffffff16(%ebp)
    2d35:       c6 85 17 ff ff ff 3f    movb   $0x3f,0xffffff17(%ebp)
    2d3c:       c6 85 18 ff ff ff 3d    movb   $0x3d,0xffffff18(%ebp)
    2d43:       c6 85 19 ff ff ff 6d    movb   $0x6d,0xffffff19(%ebp)
    2d4a:       c6 85 1a ff ff ff 5b    movb   $0x5b,0xffffff1a(%ebp)
    2d51:       c6 85 1b ff ff ff e3    movb   $0xe3,0xffffff1b(%ebp)
    2d58:       c6 85 1c ff ff ff 25    movb   $0x25,0xffffff1c(%ebp)
    2d5f:       c6 85 1d ff ff ff 5a    movb   $0x5a,0xffffff1d(%ebp)
    2d66:       c6 85 1e ff ff ff f8    movb   $0xf8,0xffffff1e(%ebp)
    2d6d:       c6 85 1f ff ff ff c3    movb   $0xc3,0xffffff1f(%ebp)

Here's the gcc -v output for the offending source file:

/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/g++ -v -save-temps -g -O3 -pipe
-fno-strict-aliasing -ansi -pthread -fexceptions -D_POSIX_C_SOURCE=199506L
-D_FILE_OFFSET_BITS=64 -gstabs+ -Wno-parentheses -Wcast-align -Wno-deprecated
-Werror -DGLNX86 -DSIMULINK_V2 -DINTERNATIONALIZE=1 -I. -I../include
-I../../include -c -o /tmp/validat1.o validat1.cpp
g++: warning: -pipe ignored because -save-temps specified
Reading specs from
/mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /home/cnewbold/src/gnu/gcc-3.4.4/configure
--enable-__cxa_atexit --prefix=/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4
Thread model: posix
gcc version 3.4.4
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-E -quiet -v -I. -I../include -I../../include -iprefix
/mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/
-D_GNU_SOURCE -D_REENTRANT -D_POSIX_C_SOURCE=199506L -D_FILE_OFFSET_BITS=64
-DGLNX86 -DSIMULINK_V2 -DINTERNATIONALIZE=1 validat1.cpp -mtune=pentiumpro -ansi
-Wno-parentheses -Wcast-align -Wno-deprecated -Werror -fno-strict-aliasing
-fexceptions -fworking-directory -O3 -o validat1.ii
ignoring nonexistent directory
"/mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4"
ignoring duplicate directory
"/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/i686-pc-linux-gnu"
ignoring duplicate directory
"/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/backward"
ignoring duplicate directory
"/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include"
ignoring nonexistent directory
"/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory "../include"
ignoring nonexistent directory "../../include"
#include "..." search starts here:
#include <...> search starts here:
 .
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/i686-pc-linux-gnu
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/backward
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include
 /usr/local/include
 /hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/include
 /usr/include
End of search list.
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-fpreprocessed validat1.ii -quiet -dumpbase validat1.cpp -mtune=pentiumpro -ansi
-auxbase-strip /tmp/validat1.o -g -gstabs+ -O3 -Wno-parentheses -Wcast-align
-Wno-deprecated -Werror -ansi -version -fno-strict-aliasing -fexceptions -o
validat1.s
GNU C++ version 3.4.4 (i686-pc-linux-gnu)
        compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /mathworks/hub/Linux/glibc-2.3.2/i686/apps/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o /tmp/validat1.o validat1.s
GNU assembler version 2.15 (i686-pc-linux-gnu) using BFD version 2.15

-- 
           Summary: Optimization stomps const, initialized local array
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cnewbold at mathworks dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug c++/22129] Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

------- Additional Comments From cnewbold at mathworks dot com  2005-06-20 20:26 -------
Created an attachment (id=9119)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9119&action=view)
pre-processed source which illustrates the bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug c++/22129] Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

------- Additional Comments From cnewbold at mathworks dot com  2005-06-20 20:36 -------
I should add that this initialization problem also occurs for one other local
arrays in the example in addition to the one already noted: the array 
"plain" on line 611.

The problem still manifests at -O2 instead of -O3, but goes away at -O1.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] Optimization stomps const, initialized local array

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-20 20:39 -------
I don't see the problem on the mainline, maybe I not understanding what you mean.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |rtl-optimization
           Keywords|                            |wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

------- Additional Comments From cnewbold at mathworks dot com  2005-06-20 20:46 -------
Subject: Re:  Optimization stomps const,
	initialized local array

On Mon, 2005-06-20 at 20:39 +0000, pinskia at gcc dot gnu dot org wrote:

> I don't see the problem on the mainline, maybe I not understanding what you mean.

The problem is that once we're past the initialization and into the body
of the block, the array does not have the correct content. In the
example I cited, the first byte of 'encrypted' does not contain 0xf3,
but instead some random trash. Here's a break down of the assembler for
the opening of that block:

First byte of 'encrypted' (correctly) loaded with 0xf3:
    2cab:       c6 85 08 ff ff ff f3    movb   $0xf3,0xffffff08(%ebp)

Something else dropped in here, which stomps the first element:
    2cb2:       ba 08 00 00 00          mov    $0x8,%edx
    2cb7:       b9 08 00 00 00          mov    $0x8,%ecx
    2cbc:       89 95 08 ff ff ff       mov    %edx,0xffffff08(%ebp)
                                               ^^^^^^^^^^^^^^^^
                                                  OOOPS!
    2cc2:       31 c0                   xor    %eax,%eax
    2cc4:       8d 55 b8                lea    0xffffffb8(%ebp),%edx
    2cc7:       89 8d 28 ff ff ff       mov    %ecx,0xffffff28(%ebp)
    2ccd:       8d 8d 30 ff ff ff       lea    0xffffff30(%ebp),%ecx

Remaining 23 bytes of 'encrypted' are loaded:
    2cd3:       c6 85 09 ff ff ff 09    movb   $0x9,0xffffff09(%ebp)
    2cda:       c6 85 0a ff ff ff 62    movb   $0x62,0xffffff0a(%ebp)
    ...

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-20 20:48 -------
on the mainline and the 4.0 branch and in 4.0.0, encrypted gets promoted to a static const which works 
around the bug.

Also note this is not a full testcase and cannot just run, so is there way to get one which is self 
contained?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Optimization stomps const,  |[3.4 only] Optimization
                   |initialized local array     |stomps const, initialized
                   |                            |local array
   Target Milestone|---                         |3.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

------- Additional Comments From cnewbold at mathworks dot com  2005-06-20 20:51 -------
Subject: Re:  [3.4 only] Optimization stomps
	const, initialized local array

On Mon, 2005-06-20 at 20:48 +0000, pinskia at gcc dot gnu dot org wrote:

> Also note this is not a full testcase and cannot just run, so is there way to get one which is self 
> contained?

Sorry, I thought just being able to inspect the assembler would be
enough for you. A full, executable test case consists of 10+ source
files. I'll see what I can do about paring it down.

-Chris



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array

[cnewbold at mathworks dot com]

------- Additional Comments From cnewbold at mathworks dot com  2005-06-21 15:50 -------
Subject: Re:  [3.4 only] Optimization stomps
	const, initialized local array

On Mon, 2005-06-20 at 20:48 +0000, pinskia at gcc dot gnu dot org wrote:

> Also note this is not a full testcase and cannot just run, so is there way to get one which is self 
> contained?

I have not had any success limiting the scope of the source required for
an executable example. The code in question comes from the
self-validation code for the open-source Crypto++ library, a C++ class
library of cryptographic primitives, version 4.2. Let me know what would
be most useful for you at this point.

One additional note, it appears that removing "-fno-strict-aliasing"
from the compiler command line also makes the problem go away even with
-O2 or -O3. I doubt this is safe, however.

-Chris



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129

[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-07-27 12:46 -------
It'll come as no surprise that this is yet another bug related
to the infamous RTX_UNCHANGING_P.  A reduced C testcase is:

    extern void abort (void);
    void f (const char *x)
    {
      if (x[0] + x[1] + x[2] != 6)
	abort ();
    }
    int main()
    {
      { struct { int x : 31; char y[5]; } s; s.x = 1; }
      { const char x[] = { 1, 2, 3 }; f (x); }
      return 0;
    }

which fails on 3.4 branch for i686-pc-linux-gnu when compiled with
"-O2 -fno-strict-aliasing".  The problem is that 's.x' and 'x[]'
are both stored in the same 32-bit stack slot and that accesses
to 'x[]' are marked as unchanging (== "set once"):

    (insn 18 17 19 (set (mem/s/j:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
		    (const_int -16 [0xfffffff0])) [0+0 S4 A128])
	    (reg:SI 58)) -1 (nil)
	(nil))
    ....
    (insn 25 24 26 (set (mem/s/u:QI (plus:SI (reg/f:SI 54 virtual-stack-vars)
		    (const_int -16 [0xfffffff0])) [0 x+0 S1 A128])
	    (const_int 1 [0x1])) -1 (nil)
	(nil))

The scheduler thinks that the two stores don't conflict and decides
to swap them around.

When using -fstrict-aliasing, the variables will be put into different
stack slots and the bug does not occur.  This is because can only use
the same stack slot for two decls if objects_must_conflict_p says that
accesses to them will always conflict.  Strict aliasing puts 's'
and 'x' into different alias sets, so objects_must_conflict_p will
return false.

There aren't separate alias sets when using -fno-strict-aliasing,
so objects_must_conflict_p lets us assign both decls to the same slot.

In a nutshell, the problem seems to be that we're setting RTX_UNCHANGING_P
based on the properties of a decl but reusing stack slots based on the
properties of a type.  (Note that objects_must_conflict_p operates on
types rather than decls.)

Since RTX_UNCHANGING_P is no more (yay), this bug should be specific to 3.4.
I'm really not sure what the best fix there would be.  Perhaps we could
just get objects_must_conflict_p to return false for arrays of constant
elements, much like it does for structures with constant fields?

Richard

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-27 12:46:09
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129