[fortran,patch] BLAS-enabled matmul

Brooks Moses bmoses@stanford.edu
Mon Apr 3 23:33:00 GMT 2006

Daniel Jacobowitz wrote:
> On Mon, Apr 03, 2006 at 11:53:24PM +0200, FX Coudert wrote:
>>2. if -fexternal-blas is specified, its argument is added instead of 
>>-lgfortran_blas, but everything else from point 1 is still valid; 
>>append_blas() breaks the space-separated words in
>>-fexternal-blas argument before appending them to the arguments. As for 
>>the order of linking, -lgfortran still needs to be added after the 
>>external blas library, because if the external library was compiled with 
>>gfortran, it might have some libgfortran symbols referred in it :)
> This is pretty nasty.  If I were designing a command line interface for
> this, it would just be "-fexternal-blas disables inclusion of the
> default libgfortran_blas.a".  Can't we get that to work?  Maybe with
> --start-group and --end-group?

That does sound clearer, yes.  I gather that what you mean is that the 
-fexternal-blas option doesn't take an argument, and the user supplies 
other options (-lmy_blas_library, or whatever) in the usual way to 
actually link in the BLAS library?

I think this would combine well in combination with my other suggestion, 
too -- the explanation there would instead be "-fexternal_blas redirects 
use of some matrix intrinsics to external BLAS calls" or something like 


One other thought, which the "if the external library was compiled with 
gfortran, it might have some libgfortran symbols referred in it" comment 
brought up upon rereading: We need to make sure that this process does 
not prevent compiling BLAS libraries on gfortran!

Ideally, it would also not prevent compiling a partial BLAS library for 
development purposes -- e.g., code that includes a DGEMM subroutine, but 
not a ZGEMM one.  The current version would, I think, either complain 
about a dgemm_ symbol clash or an undefined zgemm_ symbol, depending on 
the option chosen.

- Brooks

More information about the Gcc-patches mailing list