This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: g77 in egcs-1.1.1
- To: josip at icase dot edu
- Subject: Re: g77 in egcs-1.1.1
- From: Dave Love <d dot love at dl dot ac dot uk>
- Date: 16 Jan 1999 17:35:22 +0000
- Cc: egcs-bugs at cygnus dot com
- References: <369F6507.B77F92CF@icase.edu>
>>>>> "JL" == Josip Loncaric <josip@icase.edu> writes:
JL> LAPACK, a standard package of linear algebra routines available from
JL> http://www.netlib.org/, does not compile properly in egcs-1.1.1 under
JL> Red Hat Linux 5.2 running on a Pentium II system.
Well, there is a quite current RHCN RPM for it.
JL> The command used was:
JL> g77 -O3 -funroll-all-loops -fomit-frame-pointer -m486 -malign-double -c
JL> ...
but presumably not with those options. [Why use -m486 on a PII?]
JL> Problems:
JL> (1) Test program xlintstc dumps core:
JL> Data file for testing COMPLEX LAPACK linear equation routines
JL> xlintstc < ctest.in > ctest.out 2>&1
JL> make[1]: *** [ctest.out] Error 139
Any chance of telling us how it dumps core, perhaps with some gdb
information, and just what the source is? `find' on a netlib mirror
directory didn't reveal `*xlintstc*'. And was the whole thing
compiled as above, or just that test? I suspect it's up to me to
address this and I probably don't even have free disc space on a
suitable box to unpack and build lapack.
JL> This problem can be fixed by adding "-fno-emulate-complex" compiler
JL> switch. Clearly, there is a problem with complex arithmetic under
JL> certain conditions.
Or it tickled another bug perhaps.
JL> (2) g77 still does not allow the use of simple intrinsics like
JL> MAX() in PARAMETER statements. This prevents compilation of
JL> LAPACK timing routines in their original form. Statements like
JL> PARAMETER (LSIZE=MAX(THIS,THAT)) are so basic to most standard
JL> packages in Fortran
Well, they're not Fortran77 and AFAIK relatively few f77 packages seem
to fall foul of them. AFAIR that stuff only occurs in the lapack test
routines.
JL> that g77 should handle it. As things stand, one is forced into
JL> cumbersome and error prone code rewriting.
Would you like to contribute funds to implement that?
JL> I should mention that no problems whatsoever arise when using plain
JL> "fort77 -O" or Portland Group's "pgf77 -fast" to compile and test
JL> LAPACK. Unfortunately, fort77 produces slow code,
If you mean the f2c wrapper and it's particularly slow, I suspect you
didn't use `-a'.
JL> while the pgf77 is fast but not widely available due to cost.
JL> The egcs-1.1.1 version of g77 produces very fast code and should
JL> become widely available, but in its present form it cannot handle
JL> typical Fortran packages like LAPACK.
I think that's a bit overgeneralized.
JL> May I suggest that "compile & test LAPACK" should be one of standard
JL> tests for any Fortran compiler?
We'd welcome your resources to do such testing on prerelease versions
with whatever options interest you.