Bug 18977 - [4.0 regression] LAPACK test xeigtsts segfaults with optimization
Summary: [4.0 regression] LAPACK test xeigtsts segfaults with optimization
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Jim Wilson
URL:
Keywords: wrong-code
Depends on: 17675
Blocks: 5900 19292
  Show dependency treegraph
 
Reported: 2004-12-14 10:42 UTC by Thomas Koenig
Modified: 2005-02-18 23:11 UTC (History)
2 users (show)

See Also:
Host:
Target: ia64-unknown-linux-gnu
Build:
Known to work: 3.2.3
Known to fail:
Last reconfirmed: 2005-02-18 20:53:32


Attachments
Failing C source code (368 bytes, text/plain)
2005-01-27 15:09 UTC, Thomas Koenig
Details
Simpler example of failing C source code (268 bytes, text/plain)
2005-01-28 13:47 UTC, Thomas Koenig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2004-12-14 10:42:44 UTC
I was running the LAPACK with -O3
with 20041212 (snapshot) with Steve Kargl's I/O patch
from http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00844.html
applied.   The test ran OK until xeigtsts segfaulted:

make[1]: Entering directory `/home/zfkts/zfkts/LAPACK/TESTING'
Testing REAL LAPACK linear equation routines
./xlintsts < stest.in > stest.out 2>&1
NEP: Testing Nonsymmetric Eigenvalue Problem routines
./xeigtsts < nep.in > snep.out 2>&1
SEP: Testing Symmetric Eigenvalue Problem routines
./xeigtsts < sep.in > ssep.out 2>&1
SVD: Testing Singular Value Decomposition routines
./xeigtsts < svd.in > ssvd.out 2>&1
SEC: Testing REAL Eigen Condition Routines
./xeigtsts < sec.in > sec.out 2>&1
make[1]: *** [sec.out] Error 139
make[1]: Leaving directory `/home/zfkts/zfkts/LAPACK/TESTING'
make: *** [testing] Error 2
$ gdb ./xeigtsts
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r < sec.in
Starting program: /home/zfkts/zfkts/LAPACK/TESTING/xeigtsts < sec.in
 Tests of the Nonsymmetric eigenproblem condition estimation routines
 SLALN2, SLASY2, SLANV2, SLAEXC, STRSYL, STREXC, STRSNA, STRSEN, SLAQTR

 Relative machine precision (EPS) =     0.119209E-06
 Safe minimum (SFMIN)             =     0.117549E-37

 Routines pass computational tests if test ratio is less than   20.00


 SEC routines passed the tests of the error exits ( 35 tests done)

Program received signal SIGSEGV, Segmentation fault.
slasy2_ (ltranl=Variable "ltranl" is not available.
) at slasy2.f:362
362                 TMP( K ) = TMP( K ) - ( TEMP*T16( K, J ) )*TMP( J )
Current language:  auto; currently fortran
(gdb) p tmp
$1 = (0, -nan(0x7f6f34), 10797277, -1437623.12)

Reverting Steve's patch, bubblestrapping and rerunning it made
no difference.

This is a regression from about a month ago, and possibly a target
problem.
Comment 1 Thomas Koenig 2004-12-14 11:08:54 UTC
Same problem with -O1 . -O0 doesn't segfault.
Comment 2 Steve Kargl 2004-12-14 16:06:57 UTC
My success with LAPACK is on i386-*-FreeBSD.  LAPACK
dies a horrible death on amd64-*-FreeBSD.  Your segfault
is a BUS ERROR for me.  I believe this is a x86_64 target
problem.

-- 
steve
Comment 3 Thomas Koenig 2004-12-16 15:59:16 UTC
I reran the tests with the 20041114 snapshot at -O1, and
the segfault did indeed go away, so this is a regression.

Quite likely, this is a IA-64 target problem.
Comment 4 Thomas Koenig 2004-12-17 09:30:08 UTC
With 20041121, there was a problem with
xeigtstc hanging with -O1 on IA-64.
Comment 5 Giovanni Bajo 2005-01-06 15:43:27 UTC
I'm no Fortran guru, but could be this related to PR 17675?
Comment 6 Andrew Pinski 2005-01-06 15:46:02 UTC
Yes this is most likely PR 17675 which effects all targets where unaligned loads cause an processor 
exception (and the OS does not handle it) (ia64 is one of these targets).
Comment 7 Thomas Koenig 2005-01-06 17:01:48 UTC
(In reply to comment #5)
> I'm no Fortran guru, but could be this related to PR 17675?

I don't think this is an alignment problem.  Apparently,
ia64-unknown-linux-gnu sets up the processor differently from
HP-UX.

Test case:

$ cat equiv.f
      integer a(5)
      double precision d1,d2
      equivalence (a(1),d1), (a(4),d2)
      call foo(d1,d2)
      print *,d1,d2
      end
      subroutine foo(d1,d2)
      double precision d1,d2
      d1 = 3.14D0
      d2 = 2.71D0
      end
$ gfortran equiv.f
$ ./a.out
   3.14000000000000        2.71000000000000
$ ifort equiv.f
fortcom: Warning: equiv.f, line 2: Alignment of variable or array is
inconsistent with its data type.   [D2]
      double precision d1,d2
--------------------------^
$ ./a.out
   3.14000000000000        2.71000000000000
$ g77 equiv.f
Can't place `d1' as directed by EQUIVALENCE due to alignment restrictions
Comment 8 Steven Bosscher 2005-01-26 10:00:35 UTC
Is there a test case someone can attach to this bug? 
Comment 9 Thomas Koenig 2005-01-26 15:26:16 UTC
(In reply to comment #8)
> Is there a test case someone can attach to this bug? 

I'm working on it.  The error vanishes if slasy2.f is
compiled with -O0, which is at least a start.

An equivalent error occurs in dlasy2.f, BTW, which also goes away
if dlasy2.f is compiled with -O0.
Comment 10 Thomas Koenig 2005-01-26 17:23:36 UTC
Here we go:

$ cat sl-error.f
      implicit none
      real x(2,2)
      call foo(x)
      end
      subroutine foo(x)
      real x(2,2)
      real tmp(4), t16(4,4), btmp(4),temp

      DO 120 I = 1, 4
         K = 5 - I
         TEMP = 1.0 / T16( K, K )
         TMP( K ) = BTMP( K )*TEMP
         DO 110 J = K + 1, 4
            TMP( K ) = TMP( K ) - ( TEMP*T16( K, J ) )*TMP( J )
 110     CONTINUE
 120  CONTINUE

      X( 1, 1 ) = TMP( 1 )
      X( 2, 1 ) = TMP( 2 )
      X( 1, 2 ) = TMP( 3 )
      X( 2, 2 ) = TMP( 4 )

      end
$ gfortran sl-error.f
$ ./a.out
$ gfortran -O1 sl-error.f
$ ./a.out
Segmentation fault
$ gfortran -dumpmachine
ia64-unknown-linux-gnu
$ gfortran -v
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
Comment 11 Steve Kargl 2005-01-26 19:07:54 UTC
Thomas,

Your reduce test case compiles and runs fine on amd64-*-freebsd6.0.
This must be a target bug.

Comment 12 Thomas Koenig 2005-01-26 19:46:08 UTC
Selected component "target" instead of "fortran".
Comment 13 Thomas Koenig 2005-01-27 15:09:20 UTC
Created attachment 8084 [details]
Failing C source code

This is indeed a target bug.  I've attached a C source
code (from the t02.original file) which works OK with -O0
and generates a segfault at -O1:

$ gcc sl2-error.c
$ ./a.out
$ gcc -O1 sl2-error.c
$ ./a.out
Segmentation fault
$ gcc -v
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
$ gcc -dumpmachine
ia64-unknown-linux-gnu

This is a regression from 3.2.3:

$ /usr/bin/gcc -O3 sl2-error.c && ./a.out
$ /usr/bin/gcc -O1 sl2-error.c && ./a.out
$ /usr/bin/gcc -O0 sl2-error.c && ./a.out
$ /usr/bin/gcc -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
Comment 14 Thomas Koenig 2005-01-28 13:47:41 UTC
Created attachment 8090 [details]
Simpler example of failing C source code

This is a simpler example of failing C code (which won't
make peoples' eyes cross from looking at converted Fortran
DO loops and array indices), and which also has its variables
initialized.

The error is the same:
$ gcc -O1 sl4-error.c
$ ./a.out
Segmentation fault
$ gcc -v ; gcc -dumpmachine
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
ia64-unknown-linux-gnu
Comment 15 Thomas Koenig 2005-01-28 14:29:22 UTC
The inner loop does not terminate in this example,
until a segfault is hit.

$ cat sl5-error.c
#include <stdio.h>

void foo(float * x);

int main()
{
  float x[4];
  foo (x);
  return 0;
}

void foo (float *x)
{
    int i,j,k;
    float temp;
    static float t16[16]={1.,2.,3.,4.,5.,6.,7.,8.,9.,
                          10.,11.,12.,13.,14.,15.,16.};
    static float tmp[4]={0.,0.,0.,0.};

    for (i=0; i<4; i++) {
        k = 3 - i;
        temp = t16[5*k];
        for(j=k+1; j<4; j++) {
            printf("i=%d, j=%d, k=%d\n",i,j,k);
            tmp[k] = t16[k+  j*4] * temp;
        }
    }
    x[0] = tmp[0];
    x[1] = tmp[1];
    x[2] = tmp[2];
    x[3] = tmp[3];
}
$ gcc sl5-error.c
$ ./a.out
i=1, j=3, k=2
i=2, j=2, k=1
i=2, j=3, k=1
i=3, j=1, k=0
i=3, j=2, k=0
i=3, j=3, k=0
$ gcc -O1 sl5-error.c
$ ./a.out
i=1, j=3, k=2
i=2, j=2, k=1
i=2, j=3, k=1
i=2, j=4, k=1
i=2, j=5, k=1
i=2, j=6, k=1

... and so on, until

i=2, j=803, k=1
i=2, j=804, k=1
i=2, j=805, k=1
i=2, j=806, k=1
i=2, j=807, k=1
i=2, j=808, k=1
Segmentation fault
$ gcc -v ; gcc -dumpmachine
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
ia64-unknown-linux-gnu
Comment 16 Giovanni Bajo 2005-02-01 11:13:00 UTC
Jim, this is a ia64 regression that greatly affects Fortran (LAPACK), and there 
is a simple C testcase for it. Would you mind having a look?
Comment 17 Jim Wilson 2005-02-01 21:32:02 UTC
Subject: Re:  [4.0 regression] LAPACK test xeigtsts
	segfaults with optimization

On Tue, 2005-02-01 at 03:13, giovannibajo at libero dot it wrote:
> ------- Additional Comments From giovannibajo at libero dot it  2005-02-01 11:13 -------
> Jim, this is a ia64 regression that greatly affects Fortran (LAPACK), and there 
> is a simple C testcase for it. Would you mind having a look?

I saw the discussion, and was hoping to get a chance to look at it, but
because of personal issues it may be a few weeks before I get a chance.


Comment 18 Jim Wilson 2005-02-12 04:00:42 UTC
I have taken an initial look.  This is an ivopts problem.  Compiling with -O
-fno-ivopts works.

There is clearly something wrong with ivopts if I look at the t54.ivopts dump
file.  For the J loop iterator, I get before the loop
  # ivtmp.41_57 = PHI <ivtmp.41_58(9), 4294967296(0)>;
and inside the loop
  ivtmp.41_58 = ivtmp.41_57 - 4294967295;
Translating that into hex, we have an initial value of 0x1 00000000.  And an
increment of 0xffffffff 00000001.  The first addition produces a value of 0x1,
so a loop that iterates once works correctly.  If the loop needs to execute more
than once, we are screwed, as now the iterator ends up with useless values.

I haven't tried looking at ivopts yet, but I wonder if perhaps this is a 64-bit
hosting issue, and ivopts is getting some mixed 32-bit/64-bit arithmetic wrong.

Trying this theory, I compiled the testcase on an x86_64 system, and got the
same failure, with the same bogus iterator values.

I updated my source trees, rebuilt, and now it works on both IA-64 and x86-64. 
This bug must have been fixed sometime within the last week or two by a patch
for another ivopts PR.  It would be nice to know which one fixed it though.  I
will check to see if I can figure this out easily.
Comment 19 Thomas Koenig 2005-02-14 12:25:45 UTC
I can confirm that this is fixed in the 20050213 snapshot.
Both the reduced C test case and the original Fortran routine
don't segfault any more.  Thanks to whoever fixed this :-)


I would suggest adding sl4-error.c to the testsuite, to make
sure that this does not regress.

Thomas
Comment 20 Jim Wilson 2005-02-15 04:20:47 UTC
It was fixed by the ivopts patch for 18687, which was a patch to reduce
compilation time.  The patch says nothing about fixing bugs, or changing the
result.  It only claims to make ivopts faster.  Since this patch has no
testcase, we clearly need to add the testcase from this PR to the testsuite.

The patch that fixed it:
        http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00307.html
Comment 21 Jim Wilson 2005-02-18 20:53:32 UTC
This is a tree-optimization problem not a target problem.
Comment 22 CVS Commits 2005-02-18 23:01:44 UTC
Subject: Bug 18977

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2005-02-18 23:01:33

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/execute: loop-ivopts-1.c 

Log message:
	PR tree-optimization/18977
	* gcc.c-torture/execute/loop-ivopts-1.c: New testcase.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5050&r2=1.5051
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/loop-ivopts-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 23 Jim Wilson 2005-02-18 23:11:21 UTC
As previously noted, it was fixed by a patch from Zdenek Dvorak which had no
testcase.  This testcase has been added, and this bug report can be closed.