[Bug fortran/29516] New: Bug in character transpose

[Bug fortran/29516] New: Bug in character transpose

[fxcoudert at gcc dot gnu dot org]

The following program (adapted from our testsuite):

$ cat char_transpose_1.f90 
program main
  implicit none
  integer, parameter :: n1 = 3, n2 = 4, slen = 9
  character (len = slen), dimension (n1, n2) :: a
  integer :: i1, i2

  do i2 = 1, n2
    do i1 = 1, n1
      a (i1, i2) = 'ab'(i1:i1) // 'cde'(i2:i2) // 'cantrip'
    end do
  end do

  call test (transpose (a))
contains
  subroutine test (b)
    character (len = slen), dimension (:, :) :: b

    print *, size (b, 1), "==", n2
    print *, size(b,2), "==", n1

    do i2 = 1, n2
      do i1 = 1, n1
        print *, b (i2, i1), "==", a (i1, i2)
      end do
    end do
  end subroutine test
end program main

gives incorrect results on i386-apple-darwin, with both -m32 and -m64:

$ gfortran char_transpose_1.f90 -g -m32 && ./a.out
           4 ==           4
           4 ==           3
 accantrip==accantrip
 adcantrip==bccantrip
 aecantrip==cccantrip
 adcantrip==adcantrip
 aecantrip==bdcantrip
 aacantrip==cdcantrip
 aecantrip==aecantrip
 aacantrip==becantrip
 ,��l���==cecantrip
 aacantrip==aacantrip
 ,��l���==bacantrip
 �""==cacantrip
$ gfortran char_transpose_1.f90 -m64 && ./a.out
           4 ==           4
           4 ==           3
 accantrip==accantrip
 adcantrip==bccantrip
 aecantrip==cccantrip
 adcantrip==adcantrip
 aecantrip==bdcantrip
 aacantrip==cdcantrip
 aecantrip==aecantrip
 aacantrip==becantrip
 �==cecantrip
 aacantrip==aacantrip
 �==bacantrip
 ���==cacantrip


This is with mainline gfortran:

$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.8.1
Configured with: /gcc/configure --enable-languages=c,fortran
Thread model: posix
gcc version 4.2.0 20061019 (experimental)


The corresponding test results can be found here:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00952.html (and they don't
look too good).


-- 
           Summary: Bug in character transpose
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fxcoudert at gcc dot gnu dot org
GCC target triplet: i386-apple-darwin8.8.1


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

[Bug fortran/29516] Bug in character transpose

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-10-19 22:16 -------
The generated code emitted for the TRANSPOSE for i386-darwin is stupid:

    atmp.13.dtype = parm.12.dtype;
    atmp.13.dim[0].stride = parm.12.dim[1].stride;
    atmp.13.dim[0].lbound = parm.12.dim[1].lbound;
    atmp.13.dim[0].ubound = parm.12.dim[1].ubound;
    atmp.13.dim[1].stride = parm.12.dim[1].stride;
    atmp.13.dim[1].lbound = parm.12.dim[1].lbound;
    atmp.13.dim[1].ubound = parm.12.dim[1].ubound;
    atmp.13.data = parm.12.data;
    atmp.13.offset = parm.12.offset;

when you compare it to the (correct) code emitted on x86-linux:

    atmp.13.dtype = parm.12.dtype;
    atmp.13.dim[0].stride = parm.12.dim[1].stride;
    atmp.13.dim[0].lbound = parm.12.dim[1].lbound;
    atmp.13.dim[0].ubound = parm.12.dim[1].ubound;
    atmp.13.dim[1].stride = parm.12.dim[0].stride;
    atmp.13.dim[1].lbound = parm.12.dim[0].lbound;
    atmp.13.dim[1].ubound = parm.12.dim[0].ubound;
    atmp.13.data = parm.12.data;
    atmp.13.offset = parm.12.offset;


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|target                      |fortran
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-10-19 22:16:23
               date|                            |


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

[Bug fortran/29516] Bug in character transpose

[echristo at apple dot com]

------- Comment #2 from echristo at apple dot com  2006-10-19 22:24 -------
I'll take a look at this.


-- 

echristo at apple dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |echristo at apple dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-10-19 22:16:23         |2006-10-19 22:24:34
               date|                            |


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #3 from tobi at gcc dot gnu dot org  2006-11-25 16:12 -------
*** Bug 29977 has been marked as a duplicate of this bug. ***


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #4 from tobi at gcc dot gnu dot org  2006-11-25 16:12 -------
The duplicate contains some more analysis.


-- 


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #5 from tobi at gcc dot gnu dot org  2006-11-25 16:20 -------
With the workaround in place, I get a clean -- aside from fallout from another
patch in my tree -- testsuite run on i686-darwin


-- 


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #6 from tobi at gcc dot gnu dot org  2006-11-25 16:49 -------
Created an attachment (id=12686)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12686&action=view)
First part of the tree dumps

At FX' request, I've produced a tarball containing the tree dumps from the
compilation of trans-array.c


-- 


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #7 from tobi at gcc dot gnu dot org  2006-11-25 16:57 -------
Created an attachment (id=12687)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12687&action=view)
First part of tree dumps redux


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12686|0                           |1
        is obsolete|                            |


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #8 from tobi at gcc dot gnu dot org  2006-11-25 17:46 -------
I've given up attaching the tree dumps, they can be downloaded from
 http://www.cip.physik.uni-muenchen.de/~tobias.schlueter/dumps.tar.gz


-- 


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

[Bug fortran/29516] Bug in character transpose

[tobi at gcc dot gnu dot org]

------- Comment #9 from tobi at gcc dot gnu dot org  2006-11-25 18:50 -------
The miscompilation appears first with -O -ftree-vrp, i.e. removing -ftree-vrp
from the following command line gives a working executable, with it, we get a
broken compiler.

tobias-schluters-computer:~/src/trunk/build/gcc tobi$
/Users/tobi/src/trunk/build/./prev-gcc/xgcc
-B/Users/tobi/src/trunk/build/./prev-gcc/
-B/Users/tobi/usr/i386-apple-darwin8.8.3/bin/ -c   -O -g -ftree-vrp
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute
-Werror -fno-common   -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc
-I../../gcc/fortran -I../../gcc/../include -I./../intl
-I../../gcc/../libcpp/include -I/sw/include  -I../../gcc/../libdecnumber
-I../libdecnumber    ../../gcc/fortran/trans-array.c -o fortran/trans-array.o


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-01-02 14:46 -------
Hi Eric, any news on that one? It really is a pain, because it's apparently a
target-specific middle-end bug that miscompiles gfortran on a platform where
people are really starting to use it for production...

Just in case, here's a summary of the problem: in gcc/fortran/trans-array.c
(gfc_conv_array_transpose), the following gets miscompiled:

  for (n = 0; n < 2; n++)
    {
      dest_info->delta[n] = gfc_index_zero_node;
      dest_info->start[n] = gfc_index_zero_node;
      dest_info->stride[n] = gfc_index_one_node;
      dest_info->dim[n] = n;

      dest_index = gfc_rank_cst[n];
      src_index = gfc_rank_cst[1 - n]; // This is the miscompiled statement

      /* ... */
    }

When the statement indicated is replaced by, e.g., src_index = gfc_rank_cst[n
== 0 ? 1 : 0], everything is OK. It appears that the VRP is responsible for
that (see the tree dumps provided by Tobias).


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[tobi at gcc dot gnu dot org]

------- Comment #11 from tobi at gcc dot gnu dot org  2007-01-07 19:42 -------
We should maybe install the workaround if the optimizer bug doesn't get fixed
soon, as a Fortran FE that produces wrong code for most Fortran 90 codes is
probably not something we want.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.0 4.2.0
   Last reconfirmed|2006-10-19 22:24:34         |2007-01-09 12:59:51
               date|                            |
   Target Milestone|---                         |4.2.0


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

[Bug tree-optimization/29516] gfortran miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2007-01-09 13:14 -------
Do we know why this only fails on darwin?  If it is a VRP bug we should be able
to produce a generic testcase.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/29516] gfortran miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2007-01-09 13:33 -------
The problem is definitely the following overflowing mutliplication
which is introduced by ivopts (I'm looking at Tobias dump files):

  D.27347_74 = (union tree_node * *) n_30;
  D.27348_76 = D.27347_74 * 4294967292B;
  src_index_36 = MEM[base: &gfc_rank_cst, index: D.27348_76, offset: 4B];

VRP then (wrongly) asserts

  D.27348_76: [0B, 0B]  EQUIVALENCES: { } (0 elements)

based on (correct)

  D.27347_74: [0B, 4294967295B]  EQUIVALENCES: { } (0 elements)

and removes the index from them MEM:

  D.27347_74 = (union tree_node * *) n_30;
  D.27348_76 = D.27347_74 * 4294967292B;
  src_index_36 = MEM[base: &gfc_rank_cst, offset: 4B];


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2007-01-09 13:42 -------
(which gcc version are the dumps created with?)

First IVOPTs should not create pointer multiplication.  Really.  Second, the
problem is probably in tree-vrp.c:adjust_range_with_scev () or SCEV itself -
I guess SCEV might be confused by this multiplication as well.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/29516] gfortran miscompiled

[tobi at gcc dot gnu dot org]

------- Comment #15 from tobi at gcc dot gnu dot org  2007-01-09 14:37 -------
(In reply to comment #14)
> (which gcc version are the dumps created with?)

Should be the trunk from 2006-11-25.  Thanks for looking into this.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[tobi at gcc dot gnu dot org]

------- Comment #16 from tobi at gcc dot gnu dot org  2007-01-09 18:21 -------
Dumps from today's mainline (r120620) are at
http://www.cip.physik.uni-muenchen.de/~tobias.schlueter/dump2.tar.bz2


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #17 from mrs at apple dot com  2007-01-09 20:11 -------
Thanks delta:

$ ./xgcc -B./ -c -O t.i -fdump-tree-all &&  grep ' * 4294967292B;'
*.087t.ivopts
  D.2035_3 = D.2034_2 * 4294967292B;
$ cat t.i
typedef struct gfc_se { int pre; } gfc_se;
typedef struct gfc_ss_info { int dim[7]; } gfc_ss_info;
int gfc_rank_cst[7 + 1];
gfc_conv_array_transpose (gfc_se * se) {
  int dest, src, dest_index, src_index;
  gfc_ss_info *dest_info;
  int n;
  for (n = 0; n < 2; n++) {
    dest_info->dim[n] = n;
    src_index = gfc_rank_cst[1 - n];
    a (se->pre, b (dest, dest_index), c (src, src_index));
  }
}

this corresponds to the:  D.27348_76 = D.27347_74 * 4294967292B; line above.


-- 

mrs at apple dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at apple dot com


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

[Bug tree-optimization/29516] gfortran miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-01-09 20:32 -------
So what else is special about darwin?  I built a --enable-targets=all compiler
and am using

./cc1 -quiet -O2 t.i -fdump-tree-ivopts -march=nocona -mtune=generic

can you report how you configured gcc and how you are invoking cc1?


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #19 from rakdver at gcc dot gnu dot org  2007-01-09 20:45 -------
(In reply to comment #14)
> (which gcc version are the dumps created with?)
> 
> First IVOPTs should not create pointer multiplication.  Really.  Second, the
> problem is probably in tree-vrp.c:adjust_range_with_scev () or SCEV itself -
> I guess SCEV might be confused by this multiplication as well.

The problem is really only ivopts, creating pointer multiplication.  I have
seen this bug before, after some changes to ivopts, but it is quite hard to
reproduce -- one needs to force ivopts to generate pointer offset multiplied by
a negative number and ivopts do not do that very often (the circumstances have
to be really strange to make this appear useful).

I will prepare a patch.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #20 from mrs at apple dot com  2007-01-09 20:46 -------
You have to add -fPIC to see the bug.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2007-01-09 20:52 -------
Ok, a cross-compiler to i386-apple-darwin8.8.1 and -O -ftree-vrp -fPIC
reproduces the bug.  Defering to Zdenek for a fix.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #22 from mrs at apple dot com  2007-01-09 23:34 -------
So I'm wondering, does:

Doing diffs in .:
--- ./tree-ssa-address.c.~1~    2006-12-22 21:07:11.000000000 -0800
+++ ./tree-ssa-address.c        2007-01-09 15:30:42.000000000 -0800
@@ -483,7 +483,7 @@ addr_to_parts (aff_tree *addr, tree type
     {
       part = fold_convert (type, addr->elts[i].val);
       if (!double_int_one_p (addr->elts[i].coef))
-       part = fold_build2 (MULT_EXPR, type, part,
+       part = fold_build2 (MULT_EXPR, type, convert (sizetype, part),
                            double_int_to_tree (type, addr->elts[i].coef));
       add_to_parts (parts, type, part);
     }
--------------

fix this bug?  If so, why is that not the right patch?  With it, I get:

gfc_conv_array_transpose (se)
{
  long unsigned int D.1696;
  int * D.1697;
  int * D.1695;
  int * D.1694;
  unsigned int ivtmp.28;
  int n;
  struct gfc_ss_info * dest_info;
  int src_index;
  int dest_index;
  int src;
  int dest;
  int D.1651;
  int D.1650;
  int D.1649;
  int D.1648;

<bb 2>:

  # n_28 = PHI <n_14(4), 0(2)>
<L0>:;
  D.1694_16 = (int *) dest_info_4(D);
  D.1695_27 = (int *) n_28;
  MEM[base: D.1694_16, index: D.1695_27, step: 4B]{dest_info->dim[n]} = n_28;
  D.1696_2 = (long unsigned int) n_28;
  D.1697_3 = D.1696_2 * 4294967292B;
  src_index_6 = MEM[base: &gfc_rank_cst, index: D.1697_3, offset:
4B]{gfc_rank_cst[D.1648]};
  D.1649_8 = c (src_7(D), src_index_6);
  D.1650_11 = b (dest_9(D), dest_index_10(D));
  D.1651_13 = se_12(D)->pre;
  a (D.1651_13, D.1650_11, D.1649_8);
  n_14 = n_28 + 1;
  if (n_14 != 2) goto <L5>; else goto <L2>;

<L5>:;
  goto <bb 3> (<L0>);

<L2>:;
  return;

}


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

------- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz  2007-01-09 23:49 -------
Subject: Re:  gfortran miscompiled

> So I'm wondering, does:
> 
> Doing diffs in .:
> --- ./tree-ssa-address.c.~1~    2006-12-22 21:07:11.000000000 -0800
> +++ ./tree-ssa-address.c        2007-01-09 15:30:42.000000000 -0800
> @@ -483,7 +483,7 @@ addr_to_parts (aff_tree *addr, tree type
>      {
>        part = fold_convert (type, addr->elts[i].val);
>        if (!double_int_one_p (addr->elts[i].coef))
> -       part = fold_build2 (MULT_EXPR, type, part,
> +       part = fold_build2 (MULT_EXPR, type, convert (sizetype, part),
>                             double_int_to_tree (type, addr->elts[i].coef));
>        add_to_parts (parts, type, part);
>      }
> --------------
> 
> fix this bug?  If so, why is that not the right patch?  With it, I get:

no, it does not, you still have

>   D.1696_2 = (long unsigned int) n_28;
>   D.1697_3 = D.1696_2 * 4294967292B;

this multiplication by a pointer constant.  There are several more
places where such a MULT_EXPR's can be created.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #24 from rakdver at gcc dot gnu dot org  2007-01-10 00:04 -------
Created an attachment (id=12875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12875&action=view)
A patch

I am testing the attached patch.  It would be great if someone could test it on
i386-apple-darwin.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[pinskia at gcc dot gnu dot org]

------- Comment #25 from pinskia at gcc dot gnu dot org  2007-01-10 00:08 -------
For -fPIC testcases, you should do:
/* { dg-do compile { target fpic } } */


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #26 from mrs at apple dot com  2007-01-10 00:19 -------
Spinng a testsuite run now of Zdenek's patch...


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #27 from mrs at apple dot com  2007-01-10 00:30 -------
Breaks the build:

../../gcc/gcc/tree-ssa-address.c: In function 'tree_mem_ref_addr':
../../gcc/gcc/tree-ssa-address.c:272: warning: 'addr' is used uninitialized in
this function


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #28 from mrs at apple dot com  2007-01-10 00:48 -------
Testing with:

--- tree-ssa-address.c.~2~      2007-01-09 16:26:28.000000000 -0800
+++ tree-ssa-address.c  2007-01-09 16:34:10.000000000 -0800
@@ -244,7 +244,7 @@
 tree
 tree_mem_ref_addr (tree type, tree mem_ref)
 {
-  tree addr;
+  tree addr = NULL_TREE;
   tree act_elem;
   tree step = TMR_STEP (mem_ref), offset = TMR_OFFSET (mem_ref);
   tree sym = TMR_SYMBOL (mem_ref), base = TMR_BASE (mem_ref);

as it seemed about right.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #29 from rakdver at gcc dot gnu dot org  2007-01-10 00:55 -------
Created an attachment (id=12876)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12876&action=view)
A fixed patch.

Not quite, I forgot to rewrite several occurences of addr to addr_off in the
function.  Here is hopefully more correct version of the patch.


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12875|0                           |1
        is obsolete|                            |


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #30 from mrs at apple dot com  2007-01-10 02:51 -------
Testing looks good:

  http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00414.html


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #31 from rakdver at gcc dot gnu dot org  2007-01-11 09:02 -------
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00970.html


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2007-
                   |                            |01/msg00970.html
           Keywords|                            |patch


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #32 from rakdver at gcc dot gnu dot org  2007-01-12 00:18 -------
Subject: Bug 29516

Author: rakdver
Date: Fri Jan 12 00:17:50 2007
New Revision: 120695

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120695
Log:
        PR tree-optimization/29516
        * tree-ssa-address.c (tree_mem_ref_addr, add_to_parts,
        most_expensive_mult_to_index, addr_to_parts,
        create_mem_ref, maybe_fold_tmr): Make the type of
        fields of TARGET_MEM_REF sizetype.
        (move_fixed_address_to_symbol, move_pointer_to_base):
        New functions.
        * tree.def (TARGET_MEM_REF): Add comment on types of
        the operands.
        * gcc.dg/tree-ssa/loop-20.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-20.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-address.c
    trunk/gcc/tree.def


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[mrs at apple dot com]

------- Comment #33 from mrs at apple dot com  2007-01-17 19:13 -------
I think 4.2 would be a better release with this patch in it, could we push this
into 4.2, thanks.  Any concerns about the satefy of the patch?


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[howarth at nitro dot med dot uc dot edu]

------- Comment #34 from howarth at nitro dot med dot uc dot edu  2007-01-17 23:38 -------
Also as the gfortran developers have pointed out, this bug is currently has a
target milestone 4.2.0 which implies it was intended to be fixed in gcc 4.2
branch as well. Unfortunately, I am having trouble getting the patch checked
into gcc trunk to apply cleanly to gcc 4.2 branch.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[howarth at nitro dot med dot uc dot edu]

------- Comment #35 from howarth at nitro dot med dot uc dot edu  2007-01-19 03:02 -------
It appears that r118856, r119854 and r120156 be backported for the context of
the patch for r120695 to be correct in gcc 4.2 branch.


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #36 from rakdver at gcc dot gnu dot org  2007-01-23 21:19 -------
Patch for 4.2: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01941.html


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[rakdver at gcc dot gnu dot org]

------- Comment #37 from rakdver at gcc dot gnu dot org  2007-01-26 19:56 -------
Subject: Bug 29516

Author: rakdver
Date: Fri Jan 26 19:56:05 2007
New Revision: 121214

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121214
Log:
        PR tree-optimization/29516
        * tree-ssa-address.c (tree_mem_ref_addr, add_to_parts,
        most_expensive_mult_to_index, addr_to_parts,
        create_mem_ref, maybe_fold_tmr): Make the type of
        fields of TARGET_MEM_REF sizetype.
        (move_fixed_address_to_symbol, move_pointer_to_base,
        aff_combination_remove_elt): New functions.
        * tree.def (TARGET_MEM_REF): Add comment on types of
        the operands.
        * gcc.dg/tree-ssa/loop-20.c: New test.


Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/loop-20.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/tree-ssa-address.c
    branches/gcc-4_2-branch/gcc/tree.def


-- 


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

[Bug tree-optimization/29516] gfortran miscompiled

[fxcoudert at gcc dot gnu dot org]

------- Comment #38 from fxcoudert at gcc dot gnu dot org  2007-03-03 15:52 -------
Fixed on 4.3 and 4.2.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.2.0                       |
      Known to work|4.3.0                       |4.3.0 4.2.0
         Resolution|                            |FIXED


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