This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: g77 in egcs-1.1.1


>>>>> "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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]