[Bug c/21171] New: Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[Bug c/21171] New: Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[sami dot kantoluoto at embedtronics dot fi]

Compiling the test code with optimizations enabled generates invalid code. Data
gets read from the source table but gets not written to the destination.

Test code:
/* start of test.c */

/* compile: arm-elf-gcc -Os -c -o test.o test.c */
/*    dump: arm-elf-objdump -D test.o | more    */

typedef unsigned int u_int32_t;
typedef unsigned char u_int8_t;

#define AIC_VECTORS     32
        
typedef volatile struct AT91RM9200_AIC {
  u_int32_t             SVR[AIC_VECTORS];
} AT91RM9200_AIC_t;
         
typedef volatile struct AT91RM9200_regs {
  AT91RM9200_AIC_t      AIC;
} AT91RM9200_regs_t;
            
#define CPUReg          ((AT91RM9200_regs_t*)0xFFF00000)
        
extern const u_int32_t __IntTable[AIC_VECTORS];
        
int main()
{
  int c;
  AT91RM9200_AIC_t *aic = &CPUReg->AIC;
            
  for (c=0; c < AIC_VECTORS; c++) {
    aic->SVR[c] = __IntTable[c];
  }

  return 0;
}
/* end of test.c */

objdump output:

test.o:     file format elf32-littlearm
        
Disassembly of section .text:
        
00000000 <main>:
   0:   e59f2014        ldr     r2, [pc, #20]   ; 1c <.text+0x1c>
   4:   e59f3014        ldr     r3, [pc, #20]   ; 20 <.text+0x20>
   8:   e2822004        add     r2, r2, #4      ; 0x4
   c:   e1520003        cmp     r2, r3
  10:   1affffff        bne     4 <main+0x4>
  14:   e3a00000        mov     r0, #0  ; 0x0
  18:   e12fff1e        bx      lr

As you can see, there is no store (str) instruction at all. Code just goes
through the __IntTable[] but does nothing useful.

-- 
           Summary: Generates wrong code (w/ optimization) when copying data
                    from a table to a table in a structure
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sami dot kantoluoto at embedtronics dot fi
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-unknown-netbsdelf2.0
  GCC host triplet: i386-unknown-netbsdelf2.0
GCC target triplet: arm-unknown-elf


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

[Bug c/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[sami dot kantoluoto at embedtronics dot fi]

------- Additional Comments From sami dot kantoluoto at embedtronics dot fi  2005-04-23 08:31 -------
Created an attachment (id=8713)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8713&action=view)
A bit more simplified test file with a test code that gets compiled correctly
commented out.

Code that gets compiled _corretly_:
    *(&CPUReg->SVR[c]) = __IntTable[c];

And code that doesn't:
    CPUReg->SVR[c] = __IntTable[c];


Objdump of working code:

test.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <main>:
   0:	e59f101c	ldr	r1, [pc, #28]	; 24 <.text+0x24>
   4:	e59f001c	ldr	r0, [pc, #28]	; 28 <.text+0x28>
   8:	e4912004	ldr	r2, [r1], #4
   c:	e59f3018	ldr	r3, [pc, #24]	; 2c <.text+0x2c>
  10:	e1510003	cmp	r1, r3
  14:	e4802004	str	r2, [r0], #4
  18:	1a000000	bne	8 <main+0x8>
  1c:	e3a00000	mov	r0, #0	; 0x0
  20:	e12fff1e	bx	lr

(this could be optimized by not reloading the r3 every loop).


-- 


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

[Bug c/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[sami dot kantoluoto at embedtronics dot fi]

------- Additional Comments From sami dot kantoluoto at embedtronics dot fi  2005-04-23 08:45 -------
Created an attachment (id=8714)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8714&action=view)
objdump output of working version when compiled in thumb mode (-mthumb)

Same problems in thumb mode. Attachment shows the objdump output of the
_working_ version. Objdump output of non-working version is here:

test.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <main>:
   0:	4b03		ldr	r3, [pc, #12]	(10 <.text+0x10>)
   2:	1c1a		mov	r2, r3		(add r2, r3, #0)
   4:	3280		add	r2, #128
   6:	3304		add	r3, #4
   8:	4293		cmp	r3, r2
   a:	d1fc		bne	6 <main+0x6>
   c:	2000		mov	r0, #0
   e:	4770		bx	lr
  10:	0000		lsl	r0, r0, #0
	...
Disassembly of section .comment:

00000000 <.comment>:
   0:	43434700	cmpmi	r3, #0	; 0x0
   4:	4728203a	undefined
   8:	2029554e	eorcs	r5, r9, lr, asr #10
   c:	2e302e34	mrccs	14, 1, r2, cr0, cr4, {1}

As you can see, it does not even access the source table (non-thumb version
does).


-- 


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

[Bug target/21171] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |wrong-code


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

[Bug tree-optimization/21171] [4.0 Regression] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[rearnsha at gcc dot gnu dot org]

------- Additional Comments From rearnsha at gcc dot gnu dot org  2005-04-26 18:32 -------
Confirmed.  I suspect this is a tree loop optimization bug.  The final tree dump
has:

main ()
{
  void * D.1236;
  void * ivtmp.8;

<bb 0>:
  ivtmp.8 = &__IntTable[0];

<L0>:;
  ivtmp.8 = ivtmp.8 + 4B;
  D.1236 = &__IntTable[0] + 128B;
  if (ivtmp.8 != D.1236) goto <L0>; else goto <L2>;

<L2>:;
  return 0;

}


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
          Component|target                      |tree-optimization
     Ever Confirmed|                            |1
  GCC build triplet|i386-unknown-netbsdelf2.0   |
   GCC host triplet|i386-unknown-netbsdelf2.0   |
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-26 18:32:33
               date|                            |
            Summary|Generates wrong code (w/    |[4.0 Regression] Generates
                   |optimization) when copying  |wrong code (w/ optimization)
                   |data from a table to a table|when copying data from a
                   |in a structure              |table to a table in a
                   |                            |structure
   Target Milestone|---                         |4.0.1


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] Generates wrong code (w/ optimization) when copying data from a table to a table in a structure

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-26 19:51 -------
The problem comes from dce but the problem is that IV OPT is making the pointer as "unsigned int *", 
because the field's type is just "unsigned int[]" but since the orginal type of the struct is volatile, we 
don't have a vop as it is volatile store. And since IV opts just copies the vops and not run aliasing (which 
right now causes a different issue on 4.0 branch), we don't get a vop.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0 Regression] Generates  |[4.0/4.1 Regression]
                   |wrong code (w/ optimization)|Generates wrong code (w/
                   |when copying data from a    |optimization) when copying
                   |table to a table in a       |data from a table to a table
                   |structure                   |in a structure


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-26 22:17 -------
Removing volatile also causes the same problem,  Ok my analysis in comment #4 is not fully current, 
we still did not have a vop to begin with but since ivopts changes it to be a slightly different loop, a 
pointer based one, we need a vop as the access is no longer to a deferencing a (constant + variable).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org
 GCC target triplet|arm-unknown-elf             |
           Keywords|                            |alias
            Summary|[4.0/4.1 Regression] IV OPTS|[4.0/4.1 Regression] IV OPTS
                   |removes volatile from a type|removes does not create a
                   |or does not create a new    |new VOPs for constant values
                   |VOPs                        |


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[rakdver at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-27 14:28 -------
Subject: Bug 21171

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rakdver@gcc.gnu.org	2005-04-27 14:28:12

Modified files:
	gcc            : ChangeLog tree-ssa-loop-ivopts.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg/tree-ssa: pr21171.c 

Log message:
	PR tree-optimization/21171
	* tree-ssa-loop-ivopts.c (find_interesting_uses_address): Do not
	record address uses if the reference is volatile.
	
	* gcc.dg/tree-ssa/pr21171.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8479&r2=2.8480
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.63&r2=2.64
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5404&r2=1.5405
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21171.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-26 22:13 -------
Is it possible to backport this patch to 4.0.x?

-- 


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-02 14:35 -------
The patch did not fix the orginal testcase because the problem is with constant values.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0 Regression] IV OPTS    |[4.0/4.1 Regression] IV OPTS
                   |removes does not create a   |removes does not create a
                   |new VOPs for constant values|new VOPs for constant values


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-13 19:24 -------
Subject: Bug 21171

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	rakdver@gcc.gnu.org	2005-06-13 19:24:33

Modified files:
	gcc            : ChangeLog tree-ssa-loop-ivopts.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg/tree-ssa: pr21171.c 

Log message:
	PR tree-optimization/21171
	* tree-ssa-loop-ivopts.c (find_interesting_uses_address): Do not
	record address uses if the reference is volatile.
	
	* gcc.dg/tree-ssa/pr21171.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.285&r2=2.7592.2.286
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.49.2.3&r2=2.49.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.236&r2=1.5084.2.237
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21171.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1



-- 


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

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-13 19:43 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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