This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
libf2c/1644: lapack routine segfaults on i686, but not on sparc
- To: gcc-gnats at gcc dot gnu dot org
- Subject: libf2c/1644: lapack routine segfaults on i686, but not on sparc
- From: wilkenin at math dot lbl dot gov
- Date: 14 Jan 2001 07:17:33 -0000
- Reply-To: wilkenin at math dot lbl dot gov
>Number: 1644
>Category: libf2c
>Synopsis: lapack routine segfaults on i686, but not on sparc
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Jan 13 23:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Jon Wilkening
>Release: gcc version 2.95.2 19991024
>Organization:
>Environment:
pentium III Xeon running redhat 6.2
>Description:
I am encountering a seg-fault which I can't explain.
It occurs if I compile the code on the system above
(pentium III running redhat 6.2 under gcc 2.95.2)
and also on a pentium III running redhat 7.0 with
gcc 2.96.69. It also occurs if I download clapack
(lapack f2c'd to C) from netlib and compile everything
with gcc (instead of compiling the libraries with g77).
When I run the gdb debugger, it can walk through the
code to the very end, but can't finish the program
unless I tell it to continue, at which point it reports
"Cannot access memory at address 0xfdda3805" when I
try to go up the stack. There is no problem running
the code on a Sun Ultra Enterprise II running gcc 2.95.2
under solaris 8. I don't think the problem is with
the Lapack fortran code since it works on the sparc and
since this code is very well tested.
>How-To-Repeat:
I got the latest version of LAPACK 3.0 from netlib on 01/07/01.
I unpacked it, and:
entered LAPACK/BLAS/SRC and ran
g77 -c -O2 *.f
ar rs libblas.a *.o
entered LAPACK/SRC and ran
g77 -c -O2 *.f
ar rs liblapack.a *.o
copied libblas.a and liblapack.a into an empty directory,
created the file "broken.c" in that directory, and compiled
with
gcc broken.c -L. -llapack -lblas -lg2c -lm
the result is:
info: 0, rcond: 1.08692e-16, ferr: 1.12918e-16, berr: 1.78001e-16
Segmentation fault (core dumped)
but if I uncomment exit(1) there is no seg fault. (I can also
free all the malloc'ed space and then exit(1) with no seg fault).
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="broken.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="broken.c"
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KCnZvaWQgZGdlc3Z4XyhjaGFy
ICpGQUNULCBjaGFyICpUUkFOUywgaW50ICpOLCBpbnQgKk5SSFMsIGRvdWJsZSAqQSwKCSAgICAg
aW50ICpMREEsIGRvdWJsZSAqQUYsIGludCAqTERBRiwgaW50ICpJUElWLAoJICAgICBjaGFyICpF
UVVFRCwgZG91YmxlICpSLCBkb3VibGUgKkMsIGRvdWJsZSAqQiwgaW50ICpMREIsCgkgICAgIGRv
dWJsZSAqWCwgaW50ICpMRFgsIGRvdWJsZSAqUkNPTkQsIGRvdWJsZSAqRkVSUiwKCSAgICAgZG91
YmxlICpCRVJSLCBkb3VibGUgKldPUkssIGludCAqSVdPUkssIGludCAqSU5GTyk7CgptYWluKCkg
ewogIGRvdWJsZSByY29uZCwgZmVyciwgYmVycjsKICBjaGFyIGVxdWVkOwogIGludCBpLCBpbmZv
PTAsIG5uPTI0LCBucmhzPTEyOwogIGRvdWJsZSAqQSwgKkIsICpDOwogIGludCAqaXBpdiwgKml3
b3JrOwogIGRvdWJsZSAqQUYsICpSUiwgKkNDLCAqd29yazsKICBjaGFyICpmYWN0ID0gIkUiOwog
IGNoYXIgKnRyYW5zID0gIk4iOwoKICBBID0gKGRvdWJsZSAqKSBtYWxsb2MgKDI0KjI0KnNpemVv
Zihkb3VibGUpKTsKICBCID0gKGRvdWJsZSAqKSBtYWxsb2MgKDI0KjEyKnNpemVvZihkb3VibGUp
KTsKICBDID0gKGRvdWJsZSAqKSBtYWxsb2MgKDI0KjEyKnNpemVvZihkb3VibGUpKTsKICB3b3Jr
ID0gKGRvdWJsZSAqKSBtYWxsb2MgKDQqMjQgKiBzaXplb2YoZG91YmxlKSk7CiAgaXdvcmsgPSAo
aW50ICopIG1hbGxvYyAoMjQgKiBzaXplb2YoaW50KSk7CiAgaXBpdiA9IChpbnQgKikgbWFsbG9j
ICgyNCAqIHNpemVvZihpbnQpKTsKICBBRiA9IChkb3VibGUgKikgbWFsbG9jICgyNCoyNCAqIHNp
emVvZihkb3VibGUpKTsKICBSUiA9IChkb3VibGUgKikgbWFsbG9jICgyNCAqIHNpemVvZihkb3Vi
bGUpKTsKICBDQyA9IChkb3VibGUgKikgbWFsbG9jICgyNCAqIHNpemVvZihkb3VibGUpKTsKICAg
IAogIGZvciAoaT0wOyBpPDI0KjI0OyBpKyspCiAgICBBW2ldID0gZHJhbmQ0OCgpOyAgIAogIGZv
ciAoaT0wOyBpPDI0KjEyOyBpKyspICAKICAgIEJbaV0gPSBkcmFuZDQ4KCk7ICAgCiAgZm9yIChp
PTA7IGk8MjQqMTI7IGkrKykgIAogICAgQ1tpXSA9IGRyYW5kNDgoKTsgICAKCiAgZGdlc3Z4Xyhm
YWN0LCB0cmFucywgJm5uLCAmbnJocywgQSwgJm5uLCBBRiwgJm5uLCBpcGl2LAoJICAmZXF1ZWQs
IFJSLCBDQywgQiwgJm5uLCBDLCAmbm4sICZyY29uZCwgJmZlcnIsCgkgICZiZXJyLCB3b3JrLCBp
d29yaywgJmluZm8pOwogIAogIHByaW50ZigiaW5mbzogJWQsIHJjb25kOiAlZywgZmVycjogJWcs
IGJlcnI6ICVnXG4iLAoJIGluZm8sIHJjb25kLCBmZXJyLCBiZXJyKTsKICAKICBleGl0KDEpOwp9
Cg==