[Bug fortran/5900] Lapack regressions for g77 3.1

[Bug fortran/5900] Lapack regressions for g77 3.1

[dhazeghi@yahoo.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From dhazeghi@yahoo.com  2003-05-25 04:05 -------
Hello,

would it be possible for you to check whether this problem is still present on gcc 3.3? 
Alternatively, could you provide a self contained test-case, so that we can check directly? Thanks,

Dara



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug fortran/5900] Lapack regressions for g77 3.1

[pinskia@physics.uc.edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia@physics.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug fortran/5900] Lapack regressions for g77 3.1

[dhazeghi at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


dhazeghi at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


------- Additional Comments From dhazeghi at yahoo dot com  2003-07-05 16:57 -------
Reminder that this bug is still in waiting. Can anyone confirm whether this still occurs with gcc 
3.3? Thanks,

Dara

[Bug fortran/5900] Lapack regressions for g77 3.1

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-22 19:29 -------
I am looking at this one so do not close yet.

[Bug fortran/5900] Lapack regressions for g77 3.1

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-23 03:35:27
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-23 03:35 -------
Here are the results I get on the mainline (20030822) on powerpc-apple-darwin6.6 
(which does not have the x86 problem of exucessive precission):

cgd.out: CGV drivers:     59 out of   1092 tests failed to pass the threshold
csep.out: CST:    2 out of  4662 tests failed to pass the threshold
ded.out: DES:    2 out of  3264 tests failed to pass the threshold
ded.out: DSX:    2 out of  3494 tests failed to pass the threshold
dgd.out: DXV drivers:    200 out of   5000 tests failed to pass the threshold
dsep.out: DST drivers:      1 out of  14256 tests failed to pass the threshold
sgd.out: SXV drivers:     37 out of   5000 tests failed to pass the threshold
ssep.out: SST:    2 out of  4662 tests failed to pass the threshold
ssep.out: SST drivers:      1 out of  14256 tests failed to pass the threshold
zgd.out: ZGV drivers:     60 out of   1092 tests failed to pass the threshold
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold
total  failures 370 which is better than what 3.1 was on i686-pc-linux-gnu but still needs 
get where 2.95.2 is.

[Bug fortran/5900] [g77] Lapack regressions for g77 3.1

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-09-23 18:39 -------
Current numbers on i686 with -O0 (-O2 and higher sends xeigtsts into an infinite
loop)

Taken from: http://gcc.gnu.org/ml/fortran/2004-09/msg00218.html

	GNU Fortran 95 (GCC 4.0.0 20040919 (experimental))

 CST:    1 out of  4662 tests failed to pass the threshold
 CLS drivers:   2904 out of  65268 tests failed to pass the threshold
 DES:    1 out of  3270 tests failed to pass the threshold
 DSX:    1 out of  3500 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZGV drivers:      1 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[toon at moene dot indiv dot nluug dot nl]

------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2004-09-23 19:37 -------
CLS is hopeless - probably a real bug.

The rest is not unreasonable, compared to g77 2.95.2

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[g77] Lapack regressions for|[g77 & gfortran] Lapack
                   |g77 3.1                     |regressions since g77 2.95.2


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-09-27 19:56 -------
>From a follow-up mail to the one I referenced before, numbers with -ffast-math
only, no optimization

 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CST drivers:      2 out of  11664 tests failed to pass the threshold
 CBD:      1 out of   4085 tests failed to pass the threshold
 CLS drivers:   4050 out of  65268 tests failed to pass the threshold
 DES:    2 out of  3264 tests failed to pass the threshold
 DSX:    2 out of  3494 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

The only change is that CLS got even worse. Actually, I find it surprsing that
there are changes, I would have assumed that -ffast-math only comes into play
when optimizing.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2004-12-14 16:07 -------
Lapack on the IA-64 does not look good right now.

Here are the results with 20041212 snapshot, with Steve Kargl's I/O
patch from http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00844.html
applied:

CES:   24 out of  3276 tests failed to pass the threshold
 CEV:   92 out of   970 tests failed to pass the threshold
 CSX:   54 out of  3406 tests failed to pass the threshold
 CVX:  580 out of  5484 tests failed to pass the threshold
 CGG:    1 out of  2184 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   39 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CGE:    246 out of   3653 tests failed to pass the threshold
 CGE drivers:    146 out of   4866 tests failed to pass the threshold
 CGB:   2481 out of  28893 tests failed to pass the threshold
 CGB drivers:   2642 out of  29094 tests failed to pass the threshold
 CGT:    262 out of   2694 tests failed to pass the threshold
 CGT drivers:    282 out of   2033 tests failed to pass the threshold
 CPO:    228 out of   1628 tests failed to pass the threshold
 CPO drivers:    144 out of   1910 tests failed to pass the threshold
 CPP:    211 out of   1242 tests failed to pass the threshold
 CPP drivers:    154 out of   1865 tests failed to pass the threshold
 CPB:    657 out of   3458 tests failed to pass the threshold
 CPB drivers:    432 out of   4750 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZES:   24 out of  3276 tests failed to pass the threshold
 ZEV:   92 out of   970 tests failed to pass the threshold
 ZSX:   51 out of  3406 tests failed to pass the threshold
 ZVX:  556 out of  5472 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold
 ZHS:   39 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   31 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZGE:    246 out of   3653 tests failed to pass the threshold
 ZGE drivers:    146 out of   4866 tests failed to pass the threshold
 ZGB:   2481 out of  28893 tests failed to pass the threshold
 ZGB drivers:   2642 out of  29094 tests failed to pass the threshold
 ZGT:    262 out of   2694 tests failed to pass the threshold
 ZGT drivers:    282 out of   2033 tests failed to pass the threshold
 ZPO:    228 out of   1628 tests failed to pass the threshold
 ZPO drivers:    144 out of   1910 tests failed to pass the threshold
 ZPP:    211 out of   1242 tests failed to pass the threshold
 ZPP drivers:    154 out of   1865 tests failed to pass the threshold
 ZPB:    657 out of   3458 tests failed to pass the threshold
 ZPB drivers:    432 out of   4750 tests failed to pass the threshold

Without the I/O patch, the following additionall failures occur:

+ CPT:    120 out of   1778 tests failed to pass the threshold
+ CPT drivers:     40 out of    788 tests failed to pass the threshold
+ CHE:     62 out of   1624 tests failed to pass the threshold
+ CHE drivers:     60 out of   1072 tests failed to pass the threshold
+ CHP:     60 out of   1404 tests failed to pass the threshold
+ CHP drivers:     60 out of   1072 tests failed to pass the threshold
+ CSY:    169 out of   1864 tests failed to pass the threshold
+ CSY drivers:    168 out of   1240 tests failed to pass the threshold
+ CSP:    155 out of   1620 tests failed to pass the threshold
+ CSP drivers:    168 out of   1240 tests failed to pass the threshold
+ CTR:    348 out of   7672 tests failed to pass the threshold
+ CTP:    316 out of   7392 tests failed to pass the threshold
+ CTB:    494 out of  19888 tests failed to pass the threshold
+ CLS drivers:    900 out of  65268 tests failed to pass the threshold
+ ZPT:    120 out of   1778 tests failed to pass the threshold
+ ZPT drivers:     40 out of    788 tests failed to pass the threshold
+ ZHE:     62 out of   1624 tests failed to pass the threshold
+ ZHE drivers:     60 out of   1072 tests failed to pass the threshold
+ ZHP:     60 out of   1404 tests failed to pass the threshold
+ ZHP drivers:     60 out of   1072 tests failed to pass the threshold
+ ZSY:    169 out of   1864 tests failed to pass the threshold
+ ZSY drivers:    168 out of   1240 tests failed to pass the threshold
+ ZSP:    155 out of   1620 tests failed to pass the threshold
+ ZSP drivers:    168 out of   1240 tests failed to pass the threshold
+ ZTR:    348 out of   7672 tests failed to pass the threshold
+ ZTP:    316 out of   7392 tests failed to pass the threshold
+ ZTB:    494 out of  19888 tests failed to pass the threshold
+ ZLS drivers:    900 out of  65268 tests failed to pass the threshold

All of this is with -O0 -g.
$ cat /proc/cpuinfo
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 1
revision   : 5
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1300.000000
itc MHz    : 1300.000000
BogoMIPS   : 1946.15

processor  : 1
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 1
revision   : 5
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1300.000000
itc MHz    : 1300.000000
BogoMIPS   : 1946.15


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2004-12-14 16:13 -------
... I forgot to add, on a ia64-unknown-linux-gnu running
RedHat ES 3.0.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-01-04 06:29 -------
This is results using -O -pipe -g with:

Configured with: ../gcc/configure --prefix=/opt/gfortran --enable-
languages=c,f95Thread model: posix
gcc version 4.0.0 20050101 (experimental)


CST drivers:      1 out of  11664 tests failed to pass the threshold
CBD:      1 out of   4085 tests failed to pass the threshold
CGT:    764 out of   2694 tests failed to pass the threshold
CGT drivers:    516 out of   2033 tests failed to pass the threshold
CHE:    128 out of   1624 tests failed to pass the threshold
CHE drivers:     94 out of   1072 tests failed to pass the threshold
CHP:    124 out of   1404 tests failed to pass the threshold
CHP drivers:     94 out of   1072 tests failed to pass the threshold
CSY:     92 out of   1864 tests failed to pass the threshold
CSY drivers:     72 out of   1240 tests failed to pass the threshold
CSP:     84 out of   1620 tests failed to pass the threshold
CSP drivers:     72 out of   1240 tests failed to pass the threshold
CLS drivers:   2340 out of  65268 tests failed to pass the threshold
DXV drivers:    200 out of   5000 tests failed to pass the threshold
SXV drivers:     37 out of   5000 tests failed to pass the threshold
SST:    1 out of  4662 tests failed to pass the threshold
SST drivers:      1 out of  14256 tests failed to pass the threshold
ZXV drivers:     24 out of   5000 tests failed to pass the threshold
ZGG drivers:      1 out of   1273 tests failed to pass the threshold
ZHE:    128 out of   1624 tests failed to pass the threshold
ZHE drivers:     94 out of   1072 tests failed to pass the threshold
ZHP:    124 out of   1404 tests failed to pass the threshold
ZHP drivers:     94 out of   1072 tests failed to pass the threshold
ZSY:     73 out of   1864 tests failed to pass the threshold
ZSY drivers:     58 out of   1240 tests failed to pass the threshold
ZSP:     68 out of   1620 tests failed to pass the threshold
ZSP drivers:     58 out of   1240 tests failed to pass the threshold

I am seeing this as far back as 11/28/04.  I did a pull from cvs 10/10/04 and
the tests hang on xiegtsts.  These are on an intel P4 and much worse then my
results of 9/19/04 shown in comment 5.  I will retest from 9/19 to see if it
still works.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at verizon dot net


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-01-04 07:15 -------
OK, playing with several different dated versions and compiler options, I
discover this on a P4 (i686-pc-linux gnu).

Using -O0 -g instead of -O -pipe -g with:

Configured with: ../gcc/configure --prefix=/home/jerry/usr -enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050103 (experimental)

Gives the following which is not so bad:

 CST:    1 out of  4662 tests failed to pass the threshold
 CLS drivers:   1941 out of  65268 tests failed to pass the threshold
 DES:    1 out of  3270 tests failed to pass the threshold
 DSX:    1 out of  3500 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZGV drivers:      1 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

CLS drivers is actually a bit better then my results in comment #5

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-04 09:30 -------
Here are results on ia64-unknown-gnu-linux, with -O0 -g for
gfortran snapshot 20050102.

What I don't understand is that the results appear identical
to the ones that I showed in comment 8 with snapshot 20041212
WITHOUT Steve Kargl's I/O patch, although the problem addressed
in that patch was fixed in another way.

 CES:   24 out of  3276 tests failed to pass the threshold
 CEV:   92 out of   970 tests failed to pass the threshold
 CSX:   54 out of  3406 tests failed to pass the threshold
 CVX:  580 out of  5484 tests failed to pass the threshold
 CGG:    1 out of  2184 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   39 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CGE:    246 out of   3653 tests failed to pass the threshold
 CGE drivers:    146 out of   4866 tests failed to pass the threshold
 CGB:   2481 out of  28893 tests failed to pass the threshold
 CGB drivers:   2642 out of  29094 tests failed to pass the threshold
 CGT:    262 out of   2694 tests failed to pass the threshold
 CGT drivers:    282 out of   2033 tests failed to pass the threshold
 CPO:    228 out of   1628 tests failed to pass the threshold
 CPO drivers:    144 out of   1910 tests failed to pass the threshold
 CPP:    211 out of   1242 tests failed to pass the threshold
 CPP drivers:    154 out of   1865 tests failed to pass the threshold
 CPB:    657 out of   3458 tests failed to pass the threshold
 CPB drivers:    432 out of   4750 tests failed to pass the threshold
 CPT:    120 out of   1778 tests failed to pass the threshold
 CPT drivers:     40 out of    788 tests failed to pass the threshold
 CHE:     62 out of   1624 tests failed to pass the threshold
 CHE drivers:     60 out of   1072 tests failed to pass the threshold
 CHP:     60 out of   1404 tests failed to pass the threshold
 CHP drivers:     60 out of   1072 tests failed to pass the threshold
 CSY:    169 out of   1864 tests failed to pass the threshold
 CSY drivers:    168 out of   1240 tests failed to pass the threshold
 CSP:    155 out of   1620 tests failed to pass the threshold
 CSP drivers:    168 out of   1240 tests failed to pass the threshold
 CTR:    348 out of   7672 tests failed to pass the threshold
 CTP:    316 out of   7392 tests failed to pass the threshold
 CTB:    494 out of  19888 tests failed to pass the threshold
 CLS drivers:    900 out of  65268 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZES:   24 out of  3276 tests failed to pass the threshold
 ZEV:   92 out of   970 tests failed to pass the threshold
 ZSX:   51 out of  3406 tests failed to pass the threshold
 ZVX:  556 out of  5472 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold
 ZHS:   39 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   31 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZGE:    246 out of   3653 tests failed to pass the threshold
 ZGE drivers:    146 out of   4866 tests failed to pass the threshold
 ZGB:   2481 out of  28893 tests failed to pass the threshold
 ZGB drivers:   2642 out of  29094 tests failed to pass the threshold
 ZGT:    262 out of   2694 tests failed to pass the threshold
 ZGT drivers:    282 out of   2033 tests failed to pass the threshold
 ZPO:    228 out of   1628 tests failed to pass the threshold
 ZPO drivers:    144 out of   1910 tests failed to pass the threshold
 ZPP:    211 out of   1242 tests failed to pass the threshold
 ZPP drivers:    154 out of   1865 tests failed to pass the threshold
 ZPB:    657 out of   3458 tests failed to pass the threshold
 ZPB drivers:    432 out of   4750 tests failed to pass the threshold
 ZPT:    120 out of   1778 tests failed to pass the threshold
 ZPT drivers:     40 out of    788 tests failed to pass the threshold
 ZHE:     62 out of   1624 tests failed to pass the threshold
 ZHE drivers:     60 out of   1072 tests failed to pass the threshold
 ZHP:     60 out of   1404 tests failed to pass the threshold
 ZHP drivers:     60 out of   1072 tests failed to pass the threshold
 ZSY:    169 out of   1864 tests failed to pass the threshold
 ZSY drivers:    168 out of   1240 tests failed to pass the threshold
 ZSP:    155 out of   1620 tests failed to pass the threshold
 ZSP drivers:    168 out of   1240 tests failed to pass the threshold
 ZTR:    348 out of   7672 tests failed to pass the threshold
 ZTP:    316 out of   7392 tests failed to pass the threshold
 ZTB:    494 out of  19888 tests failed to pass the threshold
 ZLS drivers:    900 out of  65268 tests failed to pass the threshold


For comparison, here are the result with the Redhat-shipped g77
with -O0:
$ g77 -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)

CST:    1 out of  4662 tests failed to pass the threshold
CST drivers:      1 out of  11664 tests failed to pass the threshold
CST:    1 out of  4662 tests failed to pass the threshold
CST drivers:      1 out of  11664 tests failed to pass the threshold
CST drivers:      1 out of  11664 tests failed to pass the threshold
DXV drivers:    200 out of   5000 tests failed to pass the threshold
SXV drivers:     37 out of   5000 tests failed to pass the threshold
SST:    1 out of  4662 tests failed to pass the threshold
SST drivers:      1 out of  14256 tests failed to pass the threshold
ZXV drivers:     24 out of   5000 tests failed to pass the threshold

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[tobi at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |19292
              nThis|                            |


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-08 14:41 -------
SSE floating point seems to break quite a lot of single precision
complex lapack cases.  There's something wrong here.

Here are the Testresult for an Athlon XP, with Lapack compiled with
-g -march=athlon-xp -mfpmath=sse, with gfortran 20050108.

ced.out: CES:   24 out of  3276 tests failed to pass the threshold
ced.out: CEV:   92 out of   970 tests failed to pass the threshold
ced.out: CSX:   54 out of  3406 tests failed to pass the threshold
ced.out: CVX:  580 out of  5484 tests failed to pass the threshold
cgg.out: CGG:    1 out of  2184 tests failed to pass the threshold
cnep.out: CHS:   35 out of  2058 tests failed to pass the threshold
cnep.out: CHS:   39 out of  2058 tests failed to pass the threshold
cnep.out: CHS:   31 out of  2058 tests failed to pass the threshold
cnep.out: CHS:   35 out of  2058 tests failed to pass the threshold
cnep.out: CHS:   31 out of  2058 tests failed to pass the threshold
csep.out: CST:    1 out of  4662 tests failed to pass the threshold
csep.out: CST drivers:      2 out of  11664 tests failed to pass the threshold
ctest.out: CGE:    246 out of   3653 tests failed to pass the threshold
ctest.out: CGE drivers:    146 out of   4866 tests failed to pass the threshold
ctest.out: CGB:   2481 out of  28893 tests failed to pass the threshold
ctest.out: CGB drivers:   2642 out of  29094 tests failed to pass the threshold
ctest.out: CGT:    262 out of   2694 tests failed to pass the threshold
ctest.out: CGT drivers:    282 out of   2033 tests failed to pass the threshold
ctest.out: CPO:    228 out of   1628 tests failed to pass the threshold
ctest.out: CPO drivers:    144 out of   1910 tests failed to pass the threshold
ctest.out: CPP:    211 out of   1242 tests failed to pass the threshold
ctest.out: CPP drivers:    154 out of   1865 tests failed to pass the threshold
ctest.out: CPB:    657 out of   3458 tests failed to pass the threshold
ctest.out: CPB drivers:    432 out of   4750 tests failed to pass the threshold
ctest.out: CPT:    120 out of   1778 tests failed to pass the threshold
ctest.out: CPT drivers:     40 out of    788 tests failed to pass the threshold
ctest.out: CHE:     62 out of   1624 tests failed to pass the threshold
ctest.out: CHE drivers:     60 out of   1072 tests failed to pass the threshold
ctest.out: CHP:     60 out of   1404 tests failed to pass the threshold
ctest.out: CHP drivers:     60 out of   1072 tests failed to pass the threshold
ctest.out: CSY:    169 out of   1864 tests failed to pass the threshold
ctest.out: CSY drivers:    168 out of   1240 tests failed to pass the threshold
ctest.out: CSP:    155 out of   1620 tests failed to pass the threshold
ctest.out: CSP drivers:    168 out of   1240 tests failed to pass the threshold
ctest.out: CTR:    348 out of   7672 tests failed to pass the threshold
ctest.out: CTP:    316 out of   7392 tests failed to pass the threshold
ctest.out: CTB:    494 out of  19888 tests failed to pass the threshold
ctest.out: CLS drivers:   2052 out of  65268 tests failed to pass the threshold
ded.out: DES:    1 out of  3270 tests failed to pass the threshold
ded.out: DSX:    1 out of  3500 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 drivers:      1 out of  14256 tests failed to pass the threshold
zgd.out: ZGV drivers:      1 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=5900

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-01-10 04:46 -------
I have managed to reduce one of the test sets, for CLS Drivers to a case of 3
failures out of 108 tests.  Looking at the test report I am able to narrow down
to three test drivers, cqrt12.f, cqrt16.f, and cqrt17.f.

Analyzing those narrows it down to the following showing the usage of each
routine in the three tests:

	12	16	17
CLANGE	1	1	1
SASUM	1		
SLAMCH	1	1	1
SNRM2	1		
CGEBD2	1		
CLASCL	1		1
CLASET	1		
SAXPY	1		
SBDSQR	1		
SLABAD	1		
LSAME		1	1
SCASUM		1	
CGEMM		1	1
CLACPY			1
XERBLA	1		1
SLASCL	1		

I have checked out slamch and it seems to be working OK. Using grep I am getting
a count of how many other places some of thes eroutines are used.  For example
xerbla is used all over.  I think it is less likely to be the problem.  And so
it goes, a process of elimination. :)

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-01-12 04:22 -------
(In reply to comment #14)

> I have managed to reduce one of the test sets, for CLS Drivers to a case of 3
> failures out of 108 tests.  Looking at the test report I am able to
> narrow down to three test drivers, cqrt12.f, cqrt16.f, and cqrt17.f.
> Analyzing those narrows it down to the following showing the usage of each
> routine in the three tests:

That's great, Jerry! When you come up with some small testcase that you can 
post, make sure to open a different new bug report and attach the testcase 
there. We will then link it to this bug, but it's just easier to have one 
testcase/bug per bug report.


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 10:58 -------
The Lapack installation hints under
http://www.netlib.org/lapack/html/installation.hints
show that some adjustment was necessary for Crays because

# 1. The Cray compilers implement a complex divide without scaling.  To run
#    the complex linear equation tests on the T3D, I had to modify SLABAD to
#    take the square root of overflow and underflow.  I ran the eigenvalue
#    tests with the default version of SLABAD. 

Currently, gcc also uses a naive complex division algorithm without
scaling, see PR 18092.  This may be the cause of a lot of the complex
LAPACK failures.  Unfortunately, this is not easily changed, because
the scaled algorithm is currently broken, see PR 19486.

        Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 11:01 -------
PR 18902 *sigh*

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19551


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2005-01-20 22:38 -------
PR 19551 contains a reduced testcase derived from a gfortran failure in the 
CLS Driver routines.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-01-21 01:18 -------
David, Good Job!  I was on exactly the same path and was just beginning to look
at CGELSY.  Beat me to the punch! :)

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jakub at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 19551, which changed state.

Bug 19551 Summary: [3.4/4.0 Regression] pure (complex types) function call removed as dead (LAPACK routine claic1.f bug)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
             Status|NEW                         |ASSIGNED
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2005-01-24 22:48 -------
Here are gfortran-20050125 results for LAPACK on i686-pc-cygwin, after the fix 
for PR 19551 went in.  Broadly comparable to previous releases.

csep.out: CST drivers:      1 out of  11664 tests failed to pass the threshold
csep.out: CST drivers:      1 out of  11664 tests failed to pass the threshold
ctest.out: CTB:      4 out of  19888 tests failed to pass the threshold
ded.out: DES:    1 out of  3270 tests failed to pass the threshold
ded.out: DSX:    1 out of  3500 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:    2 out of  4662 tests failed to pass the threshold
ssep.out: SST drivers:      1 out of  14256 tests failed to pass the threshold
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold
zgg.out: ZGG drivers:      1 out of   1273 tests failed to pass the threshold



-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2005-01-25 00:15 -------
I forgot to mention that today's LAPACK results are with -O0.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19619


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-01-25 06:00 -------
Results on i686-pc-linux-gnu using -O0 -malign-double:

 CST:    1 out of  4662 tests failed to pass the threshold
 DES:    1 out of  3270 tests failed to pass the threshold
 DSX:    1 out of  3500 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZGV drivers:      1 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-26 09:22 -------
I have just run a Lapack test on ia64-unknown-linux-gnu, under the
following conditions:

I used the 20050123 snapshot with wide complex scaling, i.e. the fix for PR 19486
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.15&r2=2.16
and the fix for PR 19609
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.17&r2=2.18
applied.  I then set int flag_complex_divide_method = 1 in toplev.c, and
bootstrapped.

For Lapack, I used 3.0 from netlib with all files from
ftp://www.netlib.org/lapack/patch.tar.gz overwritten.

Now here are the results:

 CST:    1 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

This is BRILLIANT.  If you compare this with comment #12, the results
are identical to the g77 results.  There is no g77 regression at -O0
any more!

I think PR 18902 has just moved to critical, at least for gfortran.
I'll add a comment there.

I will rerun tests at -O1 and see what I can get.

        Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-26 09:42 -------
At -O1 on ia64-unknown-linux-gnu, I still run into PR 18977
(segfault in xeigtsts).  Pity.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |18977


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-31 14:38 -------
This is with the 20050130 snapshot on ia64-unknown-linux-gnu,
-O3 and with flag_complex_divide_method = 1.  The files slasy2.f
and dlasy2.f are compiled with -O0, to get around PR 18977.

cgd.out: CGV drivers:     61 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
ded.out: DES:    2 out of  3264 tests failed to pass the threshold
ded.out: DSX:    2 out of  3494 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:    2 out of  4662 tests failed to pass the threshold
ssep.out: SST drivers:      1 out of  14256 tests failed to pass the threshold
zgd.out: ZGV drivers:     61 out of   1092 tests failed to pass the threshold
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold

This is looking pretty good, on the whole.  The DES and DSX failures
are a bit suspect:

 N=    5, IWK= 1, seed= 100,2082,  33, 613, type 17, test( 7)= 0.450E+16
 DDRVES: DGEES1 returned INFO=     6.
         N=     5, JTYPE=    17, ISEED=(  100, 2082,   33,  613)
 N=    5, IWK= 2, seed= 100,2082,  33, 613, type 17, test( 7)= 0.450E+16
 DES:    2 out of  3264 tests failed to pass the threshold
 *** Error code from  DGEES =    6

 DGET24: DGEESX1 returned INFO=     6.
         N=     5, JTYPE=    17, ISEED=(  100, 2082,   33,  613)
 N=    5, IWK= 2, seed= 100,2082,  33, 613, type 17, test( 7)= 0.450E+16
 DSX:    2 out of  3494 tests failed to pass the threshold

The condition numbers are quite high.  There may or may not be an
optimizer bug hidden there.  I'll look around if I can isolate
anything, and open a separate PR then.

        Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-01 07:52 -------
 Using -O3 with flag_complex_divide_method = 1 in toplev.c on i686-pc-linux-gnu


 CGV drivers:     64 out of   1092 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZGV drivers:     66 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

I think this is getting there.  I will also start looking at results within for
the outliers.


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-01 08:09 -------
Note: Regarding Comment #26

All CGV failures have the same result regardless of matrix or seed:

 Matrix order=    2, type=17, seed=1661,2075,1541,1865, result  5 is 8.389E+06

All ZGV failures have the same result regardless of matrix or seed:

 Matrix order=    2, type=17, seed=1661,2075,1541,1865, result  5 is 4.504E+15

I think there is a hint here.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-02 03:29 -------
Looking at the code, the results of the tests in Comment #27 are set to this
value large number or small number when an error is detected in the results, so
they are supposed to be the same.  For the CGV failures, looks like its in the
CGGEV routine.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-07 14:03 -------
Things are strange on IA-64.

I played around a bit with different optimization levels
for xeigtstd with ded.in as input file.  I compiled everything
at -O1 and -O3, and then tried replacing single object files
with the ones compiled at -O0.

Results are as follows: When compiling one of dgemv.f or dger.f with
-O0, the failures disappear.

When compiling dnrm2.f or dtrmv.f with -O0, the failures go down to
two (from four).

All of these are BLAS routines.

Looks like some loop reordering is causing slight differences
in floating point behavior...

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-07 18:56 -------
Thomas, can you try if -O1 also produces wrong-code? Also can you try to 
selectively disable tree optimizations (-fno-tree-this, -fno-tree-that) and see 
if you find out which optimizer is triggering the miscompilation?

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-08 02:34 -------
Subject: Re:  [g77 & gfortran] Lapack regressions since
 g77 2.95.2

giovannibajo at libero dot it wrote:
> ------- Additional Comments From giovannibajo at libero dot it  2005-02-07 18:56 -------
> Thomas, can you try if -O1 also produces wrong-code? Also can you try to 
> selectively disable tree optimizations (-fno-tree-this, -fno-tree-that) and see 
> if you find out which optimizer is triggering the miscompilation?
> 
Thomas,

If you can provide me some instructions on what flags you would like to 
test and how you are doing this, I will run some cases for you if it 
would be helpful.

Jerry


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-08 05:57 -------
This seems odd, but I am getting more failures with -O0 then I do -O1, -O2, or
-O3.  The fewest failures is with -O1.  -O0 and -O3 have regressed since 2-1-05.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-08 09:24 -------
On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does.

Here's a shell script that I currently use for shotgun
testing of single optimization options:

for a in \
branch-count-reg cprop-registers \
function-cse gcse-lm \
guess-branch-probability if-conversion if-conversion2 \
ivopts keep-static-consts loop-optimize \
loop-optimize2 math-errno \
peephole sched-interblock sched-spec \
sched-stalled-insns-dep split-ivs-in-unroller \
tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \
tree-dse tree-fre tree-loop-im tree-loop-ivcanon \
tree-loop-optimize tree-lrs tree-sra tree-ter
do
        echo $a
        rm *.o
        gfortran -c -f$a ../*.f \
        && gfortran -g *.o -o xeigtstd \
        && xeigtstd < ded.in > $a.out
done

The directory above contains all the Fortran routines necessary for
xeigtstd, namely

alahdg.f  derrgg.f  dget51.f  dlaev2.f  dlarrb.f  dlatms.f  dsbev.f   dsyevr.f
alareq.f  derrhs.f  dget52.f  dlaexc.f  dlarre.f  dlatrd.f  dsbevx.f  dsyevx.f
alasum.f  derrst.f  dget53.f  dlafts.f  dlarrf.f  dlatrs.f  dsbgst.f  dsygs2.f
alasvm.f  dgbbrd.f  dget54.f  dlag2.f   dlarrv.f  dlctes.f  dsbgvd.f  dsygst.f
chkxer.f  dgbmv.f   dgetc2.f  dlagge.f  dlartg.f  dlctsx.f  dsbgv.f   dsygvd.f
dasum.f   dgebak.f  dggbak.f  dlags2.f  dlartv.f  dlsets.f  dsbgvx.f  dsygv.f
daxpy.f   dgebal.f  dggbal.f  dlagsy.f  dlaruv.f  dnrm2.f   dsbmv.f   dsygvx.f
dbdsdc.f  dgebd2.f  dgges.f   dlagtf.f  dlas2.f   dopbl3.f  dsbt21.f  dsymm.f
dbdsqr.f  dgebrd.f  dggesx.f  dlagts.f  dlascl.f  dopgtr.f  dsbtrd.f  dsymv.f
dbdt01.f  dgecon.f  dggev.f   dlagv2.f  dlasd0.f  dopla2.f  dscal.f   dsyr2.f
dbdt02.f  dgees.f   dggevx.f  dlahd2.f  dlasd1.f  dopla.f   dsecnd.f  dsyr2k.f
dbdt03.f  dgeesx.f  dggglm.f  dlahqr.f  dlasd2.f  dopmtr.f  dsgt01.f  dsyr.f
dchkbb.f  dgeev.f   dgghrd.f  dlahrd.f  dlasd3.f  dorg2l.f  dslect.f  dsyrk.f
dchkbd.f  dgeevx.f  dgglse.f  dlakf2.f  dlasd4.f  dorg2r.f  dspevd.f  dsyt21.f
dchkbk.f  dgegs.f   dggqrf.f  dlaln2.f  dlasd5.f  dorgbr.f  dspev.f   dsyt22.f
dchkbl.f  dgegv.f   dggrqf.f  dlamch.f  dlasd6.f  dorghr.f  dspevx.f  dsytd2.f
dchkec.f  dgehd2.f  dggsvd.f  dlamrg.f  dlasd7.f  dorgl2.f  dspgst.f  dsytrd.f
dchkee.f  dgehrd.f  dggsvp.f  dlangb.f  dlasd8.f  dorglq.f  dspgvd.f  dtbmv.f
dchkgg.f  dgelq2.f  dglmts.f  dlange.f  dlasda.f  dorgql.f  dspgv.f   dtgevc.f
dchkgk.f  dgelqf.f  dgqrts.f  dlanhs.f  dlasdq.f  dorgqr.f  dspgvx.f  dtgex2.f
dchkgl.f  dgemm.f   dgrqts.f  dlansb.f  dlasdt.f  dorgr2.f  dspmv.f   dtgexc.f
dchkhs.f  dgemv.f   dgsvts.f  dlansp.f  dlaset.f  dorgrq.f  dspr2.f   dtgsen.f
dchksb.f  dgeqpf.f  dhgeqz.f  dlanst.f  dlasq1.f  dorgtr.f  dspr.f    dtgsja.f
dchkst.f  dgeqr2.f  dhsein.f  dlansy.f  dlasq2.f  dorm2l.f  dspt21.f  dtgsna.f
dckglm.f  dgeqrf.f  dhseqr.f  dlanv2.f  dlasq3.f  dorm2r.f  dsptrd.f  dtgsy2.f
dckgqr.f  dger.f    dhst01.f  dlapll.f  dlasq4.f  dormbr.f  dstebz.f  dtgsyl.f
dckgsv.f  dgerq2.f  dlabad.f  dlapmt.f  dlasq5.f  dormhr.f  dstech.f  dtpmv.f
dcklse.f  dgerqf.f  dlabrd.f  dlapy2.f  dlasq6.f  dorml2.f  dstect.f  dtpsv.f
dcopy.f   dgesc2.f  dlacon.f  dlapy3.f  dlasr.f   dormlq.f  dstedc.f  dtrevc.f
ddot.f    dgesdd.f  dlacpy.f  dlaqtr.f  dlasrt.f  dormql.f  dstegr.f  dtrexc.f
ddrges.f  dgesvd.f  dladiv.f  dlar1v.f  dlassq.f  dormqr.f  dstein.f  dtrmm.f
ddrgev.f  dget02.f  dlae2.f   dlar2v.f  dlasum.f  dormr2.f  dsteqr.f  dtrmv.f
ddrgsx.f  dget10.f  dlaebz.f  dlaran.f  dlasv2.f  dormrq.f  dsterf.f  dtrsen.f
ddrgvx.f  dget22.f  dlaed0.f  dlarfb.f  dlaswp.f  dormtr.f  dstevd.f  dtrsm.f
ddrvbd.f  dget23.f  dlaed1.f  dlarf.f   dlasy2.f  dort01.f  dstev.f   dtrsna.f
ddrves.f  dget24.f  dlaed2.f  dlarfg.f  dlatb9.f  dort03.f  dstevr.f  dtrsv.f
ddrvev.f  dget31.f  dlaed3.f  dlarft.f  dlatdf.f  dpbstf.f  dstevx.f  dtrsyl.f
ddrvgg.f  dget32.f  dlaed4.f  dlarfx.f  dlatm1.f  dpotf2.f  dstt21.f  idamax.f
ddrvsg.f  dget33.f  dlaed5.f  dlarfy.f  dlatm2.f  dpotrf.f  dstt22.f  ieeeck.f
ddrvst.f  dget34.f  dlaed6.f  dlarge.f  dlatm3.f  dpptrf.f  dsvdch.f  ilaenv.f
ddrvsx.f  dget35.f  dlaed7.f  dlargv.f  dlatm4.f  dpteqr.f  dsvdct.f  lsame.f
ddrvvx.f  dget36.f  dlaed8.f  dlarhs.f  dlatm5.f  dpttrf.f  dswap.f   lsamen.f
derrbd.f  dget37.f  dlaed9.f  dlarnd.f  dlatm6.f  drot.f    dsxt1.f   xerbla.f
derrec.f  dget38.f  dlaeda.f  dlarnv.f  dlatme.f  drscl.f   dsyevd.f  xlaenv.f
derred.f  dget39.f  dlaein.f  dlarot.f  dlatmr.f  dsbevd.f  dsyev.f

There is no single optimization option that will cause any failures
for xeigtstd for ded.in *sigh*.


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-08 10:42 -------
Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and 
see if you find out something.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-08 15:36 -------
(In reply to comment #34)
> Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and 
> see if you find out something.

Still the same four failures with

#! /bin/sh
for a in \
 verbose-asm \
 cprop-registers defer-pop \
 guess-branch-probability if-conversion if-conversion2 \
 loop-optimize \
 loop-optimize2 merge-constants omit-frame-pointer \
 split-ivs-in-unroller trapping-math \
 tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \
 tree-dse tree-fre tree-loop-im tree-loop-ivcanon \
 tree-loop-optimize tree-lrs tree-sra tree-ter
do
        echo $a
        rm *.o
        gfortran -c -g -O1 -fno-$a ../*.f \
        && gfortran -c -g -O0 ../dlasy2.f \
        && gfortran -g *.o -o xeigtstd \
        && xeigtstd < ded.in > $a.out
done

The separate compilation of dlasy2.f is to get around
the segfault in PR 18977.

Any important optimization options that I've missed?

        Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-08 16:36 -------
I am not sure which of my tests of compiler options
were actually testing anything. There appears to be a bug
in passing at least one -fno - switch (see PR 19825).

Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-09 08:12 -------
gfortran -c -O1 -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce
-fno-tree-dominator-opts -fverbose-asm -fno-unswitch-loops -fno-peel-loops
-fno-unroll-loops  -fno-tree-dse -fno-tree-fre -fno-tree-loop-im
-fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra
-fno-tree-ter -fno-loop-optimize -fverbose-asm ../*.f

yields the following options:

// options passed:  -ffixed-form -auxbase -O1 -fno-tree-ccp -fno-tree-ch
// -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts
// -fverbose-asm -fno-unswitch-loops -fno-peel-loops -fno-unroll-loops
// -fno-tree-dse -fno-tree-fre -fno-tree-loop-im -fno-tree-loop-ivcanon
// -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra -fno-tree-ter
// -fno-loop-optimize
// options enabled:  -falign-loops -fargument-noalias-global
// -fbranch-count-reg -fcommon -fcprop-registers -fdefer-pop
// -feliminate-unused-debug-types -ffunction-cse -fgcse-lm
// -fguess-branch-probability -fident -fif-conversion -fif-conversion2
// -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize2
// -fmath-errno -fmerge-constants -fomit-frame-pointer -fpeephole
// -freg-struct-return -fsched-interblock -fsched-spec
// -fsched-stalled-insns-dep -fsplit-ivs-in-unroller -ftrapping-math
// -funwind-tables -fverbose-asm -fzero-initialized-in-bss -mgnu-as
// -mgnu-ld -minline-float-divide-max-throughput -mdwarf2-asm
// -mtune=itanium2

and no change in the failures.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-09 12:43 -------
See PR 19848.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-10 10:17 -------
It appears the problem is caused by one of the
optimization options that cannot be controlled with
flags.

One suspect is this code snippet from gcc/config/ia64.c :

static bool
ia64_rtx_costs (rtx x, int code, int outer_code, int *total)
{
  switch (code)

...


    case DIV:
    case UDIV:
    case MOD:
    case UMOD:
      /* We make divide expensive, so that divide-by-constant will be
         optimized to a multiply.  */
      *total = COSTS_N_INSNS (60);
      return true;


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

-- 
Bug 5900 depends on bug 19825, which changed state.

Bug 19825 Summary: -fno-loop-optimize2 does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-11 04:04 -------
Thomas, I got setup to run your script and started it running.  I then went to
look at some of the .out files to see what it was doing and on every single test
xeigtstd exits with the following message:

 ** On entry to DGEEV  parameter number  1 had an illegal value

STOP

And the tests never actually run.  Am I missing a file here or is it reading
ded.in incorrectly and erroring out? or is this some other bug?

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-11 07:56 -------
I cleared out the directory, started over and recopied the files in place.  I
get a clean execution with no errors with -O1 using g77.  When I rm *.o and
recompile with gfortran execution of ./xeigtstd < ded.in results as follows:

   -O1   execution hangs in infinite loop
   -O0    DES:    1 out of  3270 tests failed to pass the threshold
          DSX:    1 out of  3500 tests failed to pass the threshold
   -01   with numerous -fno-OPTIMIZATIONS it still hangs

When I go to the LAPACK directories and run the clean builds and make testing,
xeigtstd < ded.in completes execution.  The only difference between this and the
 above hangs is that the MATGEN and BLAS routines are compiled into static
libraries as an intermediate step.  I am using a script to completely rm all .o
and libraries before rebuilding LAPACK.

Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/jerry/usr --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050210 (experimental)



-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-02-11 08:18 -------
For what its worth, with the files all in the one directory.  g77 passes on -O0
and -O1, and hangs on -O2 and -O3.  Test set up is as in Comment #33.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-11 12:09 -------
(In reply to comment #39)

> One suspect is this code snippet from gcc/config/ia64.c :
> 
> static bool
> ia64_rtx_costs (rtx x, int code, int outer_code, int *total)

>     case DIV:
>     case UDIV:
>     case MOD:
>     case UMOD:
>       /* We make divide expensive, so that divide-by-constant will be
>          optimized to a multiply.  */
>       *total = COSTS_N_INSNS (60);

That's not it.  I changed that one to a low value, and still got
the same results.

Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-02-11 12:10 -------
(In reply to comment #40)

>  ** On entry to DGEEV  parameter number  1 had an illegal value

I had that one, as well.  There are some routines which occur more than
once.  Copying the files from the right directories solved that problem.

Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[wilson at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 18977, which changed state.

Bug 18977 Summary: [4.0 regression] LAPACK test xeigtsts segfaults with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[rth at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 18902, which changed state.

Bug 18902 Summary: Naive (default) complex division algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2005-02-28 05:13 -------
With cygwin gfortran-4.0 20050227 at -O0 I get excellent results:

csep.out: CST:    1 out of  4662 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
ctest.out: CTB:      4 out of  19888 tests failed to pass the threshold
ded.out: DES:    1 out of  3270 tests failed to pass the threshold
ded.out: DSX:    1 out of  3500 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 drivers:      1 out of  14256 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=5900

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2005-03-02 00:05 -------
and with gfortran 4.1 20040301 at -O2 I get:

csep.out: CST drivers:      1 out of  11664 tests failed to pass the threshold
csep.out: CST:    1 out of  4662 tests failed to pass the threshold
ctest.out: CTR:     12 out of   7672 tests failed to pass the threshold
ctest.out: CTP:     12 out of   7392 tests failed to pass the threshold
ctest.out: CTB:     52 out of  19888 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

PR19693 is gone, but there may be a problem with the stest.out routines. 

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 19693, which changed state.

Bug 19693 Summary: optimization problem with LAPACK routine cgtts2.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[billingd at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 19619, which changed state.

Bug 19619 Summary: LAPACK optimisation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19619

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[rth at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 19974, which changed state.

Bug 19974 Summary: incorrect complex division on ia-64 with flag_complex_method = 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME

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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[fxcoudert at gcc dot gnu dot org]

------- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-29 14:03 -------
On i386-linux, I get:

Running LAPACK tests on gfortran version 4.1.0 20050429 (experimental)
Using optimisation flags: -O0
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 CST:    2 out of  4662 tests failed to pass the threshold
 CST:    2 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 DES:    1 out of  3270 tests failed to pass the threshold
 DSX:    1 out of  3500 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    2 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold
 ZGG drivers:      1 out of   1268 tests failed to pass the threshold

Running LAPACK tests on gfortran version 4.1.0 20050429 (experimental)
Using optimisation flags: -O1
 CST:    2 out of  4662 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

-O2 segfaults, I'm looking into it.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-04-30 05:06 -------
I am getting serious regressions here.  i686-pc-linux-gnu

gcc version 4.1.0 20050430 (experimental)

with -O2

cbb.out: ZBB:   11 out of  3000 tests failed to pass the threshold
cbb.out: ZBB:   12 out of  3000 tests failed to pass the threshold
cgd.out: CGV drivers:     94 out of   1092 tests failed to pass the threshold
cgd.out: CGS drivers:     16 out of   1560 tests failed to pass the threshold
cgg.out: CGG:   20 out of  2184 tests failed to pass the threshold
cgg.out: CGG drivers:     18 out of   1274 tests failed to pass the threshold
cgg.out: CGG:   20 out of  2184 tests failed to pass the threshold
cgg.out: CGG drivers:     18 out of   1274 tests failed to pass the threshold
cgg.out: CGG:   20 out of  2184 tests failed to pass the threshold
cgg.out: CGG drivers:     18 out of   1274 tests failed to pass the threshold
cgg.out: CGG:   23 out of  2184 tests failed to pass the threshold
cgg.out: CGG drivers:     18 out of   1274 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
zbb.out: ZBB:   10 out of  3000 tests failed to pass the threshold
zbb.out: ZBB:   10 out of  3000 tests failed to pass the threshold
zgd.out: ZGV drivers:     89 out of   1092 tests failed to pass the threshold
zgd.out: ZGS drivers:     15 out of   1560 tests failed to pass the threshold
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold
zgg.out: ZGG:   22 out of  2184 tests failed to pass the threshold
zgg.out: ZGG drivers:     18 out of   1274 tests failed to pass the threshold
zgg.out: ZGG:   20 out of  2184 tests failed to pass the threshold
zgg.out: ZGG drivers:     18 out of   1274 tests failed to pass the threshold
zgg.out: ZGG:   20 out of  2184 tests failed to pass the threshold
zgg.out: ZGG drivers:     18 out of   1274 tests failed to pass the threshold
zgg.out: ZGG:   20 out of  2184 tests failed to pass the threshold
zgg.out: ZGG drivers:     18 out of   1274 tests failed to pass the threshold


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[fxcoudert at gcc dot gnu dot org]

------- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-02 10:06 -------
Similar regressions for me (gfortran version 4.1.0 20050502 on i386-linux). Only
present at -O2 and -O3.  Still very good results with -O0 and -O1 (same as
comment #47).

I understand there's heavy work on SSA right now, this could be related.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

------- Additional Comments From jvdelisle at verizon dot net  2005-06-08 06:04 -------
This is looking much better now.  Compiled with -O2 -march=pentium4

gcc version 4.1.0 20050607 (experimental)

 CGV drivers:     64 out of   1092 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 ZGV drivers:     65 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[fxcoudert at gcc dot gnu dot org]

------- Comment #51 from fxcoudert at gcc dot gnu dot org  2005-10-03 12:50 -------
Some recent results on i686-linux:

Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental)
Using optimisation flags: -O0
 CST:    2 out of  4662 tests failed to pass the threshold
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 DES:    1 out of  3270 tests failed to pass the threshold
 DSX:    1 out of  3500 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SST:    2 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 ZGG drivers:      1 out of   1268 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental)
Using optimisation flags: -O1 -march=pentium4
 CST drivers:      1 out of  11664 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental)
Using optimisation flags: -O2 -march=pentium4
 CGV drivers:     67 out of   1092 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 ZGV drivers:     66 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold

Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental)
Using optimisation flags: -O2 -funroll-loops -march=pentium4
 CGV drivers:     67 out of   1092 tests failed to pass the threshold
 CST:    1 out of  4662 tests failed to pass the threshold
 DXV drivers:    200 out of   5000 tests failed to pass the threshold
 SST:    1 out of  4662 tests failed to pass the threshold
 SST drivers:      1 out of  14256 tests failed to pass the threshold
 SXV drivers:     37 out of   5000 tests failed to pass the threshold
 ZGV drivers:     66 out of   1092 tests failed to pass the threshold
 ZXV drivers:     24 out of   5000 tests failed to pass the threshold


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2003-08-23 03:35:27         |2005-10-03 12:50:13
               date|                            |


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at gcc dot gnu dot org]

------- Comment #52 from jvdelisle at gcc dot gnu dot org  2005-10-17 02:02 -------
I would like to propose that this bug be closed.  This is about as good as it
gets.  We should set up some automatic regression testing on LAPACK from hence
forth.

With -O1 -march=pentium4:

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
zgd.out: ZXV drivers:     24 out of   5000 tests failed to pass the threshold


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[david dot billinghurst at comalco dot riotinto dot com dot au]

------- Comment #53 from david dot billinghurst at comalco dot riotinto dot com dot au  2005-10-17 02:45 -------
Subject: RE:  [g77 & gfortran] Lapack regressions since g77 2.95.2

I agree.  All but three of the failures are known LAPACK problems,
>From memory the other three failures just miss the acceptance criteria.

Just for the record, the LAPACK FAQ http://www.netlib.org/lapack/faq.html
states:

"The only known testing failures are in condition number estimation routines in
the generalized nonsymmetric eigenproblem testing. Specifically in sgd.out,
dgd.out, cgd.out and zgd.out. The cause for the failures of some test cases is
that the mathematical algorithm used for estimating the condition numbers could
over- or under-estimate the true values in a certain factor in some rare cases.
Further details can be found in LAPACK Working Note 87."


NOTICE
This e-mail and any attachments are private and confidential and may contain
privileged information. If you are not an authorised recipient, the copying or
distribution of this e-mail and any attachments is prohibited and you must not
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[steven at gcc dot gnu dot org]

------- Comment #54 from steven at gcc dot gnu dot org  2005-10-23 21:19 -------
Following comments #52 and #53, I'm removing the wrong-code keyword.

I'm all for closing this long-open bug.  But maybe we should keep it open until
some automatic testing process is in place.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at gcc dot gnu dot org]

------- Comment #55 from jvdelisle at gcc dot gnu dot org  2006-01-01 02:50 -------
$ gfc -v
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 20051228 (experimental)

Results with no optimizations:

csep.out: CST drivers:      1 out of  11664 tests failed to pass the threshold
csep.out: CST:    2 out of  4662 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
ded.out: DES:    1 out of  3270 tests failed to pass the threshold
ded.out: DSX:    1 out of  3500 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:    2 out of  4662 tests failed to pass the threshold
ssep.out: SST drivers:      1 out of  14256 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=5900

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[paul dot richard dot thomas at cea dot fr]

------- Comment #56 from paul dot richard dot thomas at cea dot fr  2006-06-01 07:31 -------
Jerry,

Where are we with this one?  Did you have time yet to automatize the testing?

It would be real nice to close it!

Paul


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at gcc dot gnu dot org]

------- Comment #57 from jvdelisle at gcc dot gnu dot org  2006-06-02 00:17 -------
Closing.  I have regular testing on my list.  Last I checked the gcc farm did
not have daily gcc builds going yet.  I was keying off that because I did not
want to do my own builds on the garm. I will keep at it.


-- 

jvdelisle at gcc dot gnu dot org changed:

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


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