[Bug regression/26001] New: LAPACK testsuite failure with optimization

[Bug regression/26001] New: LAPACK testsuite failure with optimization

[jvdelisle at gcc dot gnu dot org]

The LAPACK testsuite fails with the following error message with -O3
-march=pentium4 -funroll-loops:

At line 1162 of file schkee.f
Fortran runtime error: Bad integer for item 1 in list input

This is not a gfortran frontend problem because LAPACK passes fine without
optimization.

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../main/configure --prefix=/home/jerry/gcc/usr
--enable-languages=c,fortran --disable-libmudflap
Thread model: posix
gcc version 4.2.0 20060126 (experimental)

I have not tried 4.1 yet.  This might be considered critical considering the
widespread use of LAPACK.


-- 
           Summary: LAPACK testsuite failure with optimization
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jvdelisle at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug regression/26001] LAPACK testsuite failure with optimization

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2006-01-28 07:12 -------
Created an attachment (id=10746)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10746&action=view)
Source file that fails.

Attached is the source file.


-- 


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

[Bug regression/26001] LAPACK testsuite failure with optimization

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-01-28 07:13 -------
I have confirmed this failure is in 4.1 as well.


-- 


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

[Bug regression/26001] LAPACK testsuite failure with optimization

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2006-01-30 18:42 -------
For a reduced testscase see

http://gcc.gnu.org/ml/fortran/2006-01/msg00407.html


-- 


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

[Bug fortran/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-01-30 18:49 -------
I have a feeling it is one of the string patches that went in around the 8th.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|regression                  |fortran
            Summary|LAPACK testsuite failure    |[4.1/4.2 Regression] LAPACK
                   |with optimization           |testsuite failure with
                   |                            |optimization
   Target Milestone|---                         |4.1.0


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

[Bug fortran/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[tobi at gcc dot gnu dot org]

------- Comment #5 from tobi at gcc dot gnu dot org  2006-01-30 18:51 -------
There were not many changes to the tree during that time.  I think the only
possible culprit is Feng Wang's patch for length-one characters.


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org,
                   |                            |fengwang at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-30 18:51:54
               date|                            |


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

[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-01-30 18:59 -------
It was the patch which changed string(c:c) == string1(c:c) to be inlined but it
is a latent bug from looking at the tree dumps.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |tree-optimization


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

[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-01-30 19:02 -------
Complete unrolling is causing it but I have not looked why.


-- 

pinskia 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=26001

[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[tobi at gcc dot gnu dot org]

------- Comment #8 from tobi at gcc dot gnu dot org  2006-01-30 19:07 -------
Did the regression also happen on 4.1?  We should probably revert Feng Wang's
patch there.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-01-30 19:08 -------
Actually it is not complete unrolling that is going wrong but expand.

  static char intstr[1:10] = "0123456789";

;; if (c1$1 == intstr[1]{lb: 1 sz: 1}) (void) 0; else goto <L35>;
(insn 85 83 86 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:QI 68 [ c1$1 ])
            (const_int 49 [0x31]))) -1 (nil)
    (nil))


See how we compare that again '1' and not '0'.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |middle-end


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

[Bug middle-end/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-01-30 19:13 -------
(In reply to comment #8)
> Did the regression also happen on 4.1?  We should probably revert Feng Wang's
> patch there.

But there is a latent bug.  I don't know a way to reproduce this without Feng's
patch in C or C++, maybe Ada.  But the bug is still there.

Here is the reduced testcase that passes at -O0 but fails at -O1.
CHARACTER*10       INTSTR
CHARACTER          C1
DATA               INTSTR / '0123456789' /

C1 = INTSTR(1:1)
print *, C1
if(C1 .ne. '0')  call abort()

end


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[tobi at gcc dot gnu dot org]

------- Comment #11 from tobi at gcc dot gnu dot org  2006-01-30 19:23 -------
(In reply to comment #10)
> (In reply to comment #8)
> > Did the regression also happen on 4.1?  We should probably revert Feng Wang's
> > patch there.
> 
> But there is a latent bug.  I don't know a way to reproduce this without Feng's
> patch in C or C++, maybe Ada.  But the bug is still there.

I'm not sure what you're trying to say, so let me rephrase: given the advanced
state of 4.1 in the relase cycle, it may make sense to revert Feng Wang's patch
in 4.1, and to fix the underlying bug only in the trunk.

> Here is the reduced testcase that passes at -O0 but fails at -O1.
> CHARACTER*10       INTSTR
> CHARACTER          C1
> DATA               INTSTR / '0123456789' /
> 
> C1 = INTSTR(1:1)
> print *, C1
> if(C1 .ne. '0')  call abort()
> 
> end

Thanks, do you still get '1' in the RTL dump if you change INSTR?  IOW, does it
address the elements of the string incorrectly,

  if (c1[1]{lb: 1 sz: 1} != "0"[1]{lb: 1 sz: 1})
                               ^^^
this (t02.original) looks like a possible off-by-one error.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2006-01-30 19:27 -------
(In reply to comment #11)
> I'm not sure what you're trying to say, so let me rephrase: given the advanced
> state of 4.1 in the relase cycle, it may make sense to revert Feng Wang's patch
> in 4.1, and to fix the underlying bug only in the trunk.

That might be a good idea, I was just not thinking too well today for some
reason.

> > Here is the reduced testcase that passes at -O0 but fails at -O1.
> > CHARACTER*10       INTSTR
> > CHARACTER          C1
> > DATA               INTSTR / '0123456789' /
> > 
> > C1 = INTSTR(1:1)
> > print *, C1
> > if(C1 .ne. '0')  call abort()
> > 
> > end
> 
> Thanks, do you still get '1' in the RTL dump if you change INSTR?  IOW, does it
> address the elements of the string incorrectly,
> 
>   if (c1[1]{lb: 1 sz: 1} != "0"[1]{lb: 1 sz: 1})
>                                ^^^
> this (t02.original) looks like a possible off-by-one error.

[1] here is correct, the arrary bounds is 1:1 and not the C array bounds
starting at 0.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-01-30 19:32 -------
(In reply to comment #12)
> > this (t02.original) looks like a possible off-by-one error.
> 
> [1] here is correct, the arrary bounds is 1:1 and not the C array bounds
> starting at 0.

I should mention the off by the one error is in expand, where it forgets to
take into account the lower bound of the array.

I will be fixing this after my current bootstrap/test finishes for a different
expand bug.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[tobi at gcc dot gnu dot org]

------- Comment #14 from tobi at gcc dot gnu dot org  2006-01-30 19:37 -------
(In reply to comment #13)
> (In reply to comment #12)
> > > this (t02.original) looks like a possible off-by-one error.
> > 
> > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds
> > starting at 0.
> 
> I should mention the off by the one error is in expand, where it forgets to
> take into account the lower bound of the array.

(In reply to comment #13)
> (In reply to comment #12)
> > > this (t02.original) looks like a possible off-by-one error.
> > 
> > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds
> > starting at 0.
> 
> I should mention the off by the one error is in expand, where it forgets to
> take into account the lower bound of the array.

Sounds like the tree-optimizers should have replaced "0"[1] with '0'.  This
also sounds like it was pure chance that the bug didn't trigger at -O0.

> I will be fixing this after my current bootstrap/test finishes for a different
> expand bug.

Thanks.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2006-01-30 19:39 -------
(In reply to comment #14)
> Sounds like the tree-optimizers should have replaced "0"[1] with '0'.  This
> also sounds like it was pure chance that the bug didn't trigger at -O0.

Yes they should have but that is a tottally different issue which was filed (I
forgot the number).


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-01-31 04:56 -------
The bug is around expr.c:7128.
Working on this.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2006-01-31 05:19 -------
Created an attachment (id=10765)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10765&action=view)
Patch which still needs to bootstrap/tested but it works on my simple example

ChangeLog:
* expr.c (expand_expr_real_1) <case ARRAY_REF>:  Use the corrected index for
the character
out of the string constant.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-01-31 05:33 -------
Note if PR 22303 was fixed, then the code in expr.c could be removed.


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2006-01-31 06:39 -------
I ran the full LAPACK test suite and it successfully passes with the patch in
comment #17.  Results are pretty good/typical for -O3.

$ grep fail *.out
cgd.out: CGV drivers:     67 out of   1092 tests failed to pass the threshold
csep.out: CST:    2 out of  4662 tests failed to pass the threshold
csep.out: CST drivers:      1 out of  11664 tests failed to pass the threshold
dgd.out: DXV drivers:    200 out of   5000 tests failed to pass the threshold
sgd.out: SXV drivers:     37 out of   5000 tests failed to pass the threshold
ssep.out: SST:    1 out of  4662 tests failed to pass the threshold
ssep.out: SST drivers:      1 out of  14256 tests failed to pass the threshold
ssvd.out: SBD:      1 out of   5510 tests failed to pass the threshold
zgd.out: ZGV drivers:     66 out of   1092 tests failed to pass the threshold
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold


-- 


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #20 from pinskia at gcc dot gnu dot org  2006-01-31 14:05 -------
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02187.html


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2006-02-01 01:04 -------
Fixed on the mainline for now and I will ask Mark what we should do for 4.1.0
tomorrow.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 Regression] expand |[4.1 Regression] expand uses
                   |uses the wrong part of the  |the wrong part of the string
                   |string for array accesses   |for array accesses


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

[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2006-02-01 01:03 -------
Subject: Bug 26001

Author: pinskia
Date: Wed Feb  1 01:03:52 2006
New Revision: 110465

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110465
Log:
2006-01-31  Andrew Pinski  <pinskia@physics.uc.edu>

        PR middle-end/26001
        * gfortran.dg/data_char_2.f90: New.
2006-01-31  Andrew Pinski  <pinskia@physics.uc.edu>

        PR middle-end/26001
        * expr.c (expand_expr_real_1) <case ARRAY_REF>:
        Use the corrected index for the character
        out of the string constant.


Added:
    trunk/gcc/testsuite/gfortran.dg/data_char_2.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses

[mmitchel at gcc dot gnu dot org]

------- Comment #23 from mmitchel at gcc dot gnu dot org  2006-02-01 03:09 -------
This is not release-critical, until/unless someone has a C/C++ test case. 
However,  if the change is approved for mainline, and applies to 4.1, then it
is OK for 4.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


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

[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #25 from pinskia at gcc dot gnu dot org  2006-02-03 18:31 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses

[pinskia at gcc dot gnu dot org]

------- Comment #24 from pinskia at gcc dot gnu dot org  2006-02-03 18:31 -------
Subject: Bug 26001

Author: pinskia
Date: Fri Feb  3 18:31:14 2006
New Revision: 110551

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110551
Log:
2006-01-31  Andrew Pinski  <pinskia@physics.uc.edu>

        PR middle-end/26001
        * expr.c (expand_expr_real_1) <case ARRAY_REF>:
        Use the corrected index for the character
        out of the string constant.

2006-01-31  Andrew Pinski  <pinskia@physics.uc.edu>

        PR middle-end/26001
        * gfortran.dg/data_char_2.f90: New. 



Added:
    branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/data_char_2.f90
      - copied unchanged from r110465,
trunk/gcc/testsuite/gfortran.dg/data_char_2.f90
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/expr.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses

[fengwang at gcc dot gnu dot org]

------- Comment #26 from fengwang at gcc dot gnu dot org  2006-02-04 07:51 -------
Andrew, thank you for fixing this so quickly. 


-- 


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