From mboxrd@z Thu Jan 1 00:00:00 1970 From: wilkenin@math.lbl.gov To: gcc-gnats@gcc.gnu.org Subject: libf2c/1644: lapack routine segfaults on i686, but not on sparc Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010114071733.10272.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00273.html List-Id: >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== >>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001 From: neil@gcc.gnu.org To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c/529 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010218183600.6074.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg01458.html Content-length: 518 The following reply was made to PR c/529; it has been noted by GNATS. From: neil@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, im14u2c@primenet.com, nobody@gcc.gnu.org Cc: Subject: Re: c/529 Date: 18 Feb 2001 18:33:23 -0000 Synopsis: -Wshadow warns on function prototypes vs. global vars State-Changed-From-To: open->analyzed State-Changed-By: neil State-Changed-When: Sun Feb 18 10:33:23 2001 State-Changed-Why: Confirmed as known bug. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=529&database=gcc