Re: Possible segfault issue in alpha GOTO

[R Clint Whaley <rwhaley@cs.utk.edu>]

Since I've never built a dynamically linked lib in my life, I'm not sure
I can be of great help here.  Goto provides a performance patch for ATLAS
(I have never scoped it out, just found it today).  It's not a bug fix, but
it does change the way memory is used by his routines.  You might give it
a scope:
   http://members.jcom.home.ne.jp/kgoto/performance_tips_for_atlas.html

>Here is what I know so far:
>1) Compiling and testing ev4 config with gcc/g77 2.95 -- check
>	(i.e. no GOTO assembler, xdl3blastst dynamically linked)
>
>2) Compiling and testing ev5 config with gcc/g77 2.95 -- fail
>	(i.e. with GOTO assembler, xdl3blastst dynamically linked)
>
>3) Compiling and testing ev5 config with gcc/g77 2.95 
>	and xdl3blastst statically linked  -- check
>
>4) Compiling and testing ev5 config with gcc/g77 2.95 
>	and xdl3blastst has only one of reference blas and libatlas 
>	dynamically linked  -- check
>
>5) Compiling and testing ev5 config with gcc/g77 2.95 
>	with xdl3blastst having both  reference blas and libatlas 
>	dynamically linked  using g77-3.0  -- fail

>6) Compiling and testing ev5 config with gcc/g77 2.95 
>	with xdl3blastst having both  reference blas and libatlas 
>	dynamically linked and statically linking libg2c.a from
>	2.95.4 tree using either gcc-3.0 or g77-3.0  -- check

Again, I'm not the guy here, but doesn't 5-6 indicate it is a gcc/g77 version
difference causing the problem?

Clint