--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--
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
--- 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:
--
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
--
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
--- 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
--
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
--
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
--- 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
--- 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,
--
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 \
--- 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
--
--- 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
--- 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
--- 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,
--- 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.
--
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--
What|Removed |Added
BugsThisDependsOn||19619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- 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
--- 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
--- 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
--
What|Removed |Added
BugsThisDependsOn||19551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- 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
--- 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
--- 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
--- 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
--- 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
--
What|Removed |Added
OtherBugsDependingO||19292
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- 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
--- 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
--- 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
--- 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:
--- 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
57 matches
Mail list logo
