Segfault when running tests after compiling 0.2.3 on OSX 10.8.2

[smcallis]

I'm trying to get Julia compiled, and I've run into a snag with the OpenBLAS 0.2.3 compilation:

(build with make CC="clang -mmacosx-version-min=10.6" FC="gfortran" FFLAGS="-ff2c -O2 -fPIC" USE_THREAD=1)

OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./dblat1
Real BLAS Test Program Results

Test of subprogram number 1 DDOT
----- PASS -----

Test of subprogram number 2 DAXPY
----- PASS -----

Test of subprogram number 3 DROTG
----- PASS -----

Test of subprogram number 4 DROT
----- PASS -----

Test of subprogram number 5 DCOPY
----- PASS -----

Test of subprogram number 6 DSWAP
----- PASS -----

Test of subprogram number 7 DNRM2
----- PASS -----

Test of subprogram number 8 DASUM
----- PASS -----

Test of subprogram number 9 DSCAL
----- PASS -----

Test of subprogram number 10 IDAMAX
----- PASS -----
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./cblat1
Complex BLAS Test Program Results

Test of subprogram number 1 CDOTC

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x100019bbe
#1 0x10001a2d4
#2 0x7fff98d598e9

gfortran -ff2c -O2 -o cblat2 cblat2.o ../libopenblas_sandybridgep-r0.2.3.a -lpthread -lgfortran -lpthread -lgfortran
gfortran -ff2c -O2 -o zblat2 zblat2.o ../libopenblas_sandybridgep-r0.2.3.a -lpthread -lgfortran -lpthread -lgfortran
rm -f ?BLAT2.SUMM
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat
make[1]: *** [level1] Segmentation fault: 11
make[1]: *** Waiting for unfinished jobs....
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./dblat2 < ./dblat2.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./cblat2 < ./cblat2.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./zblat2 < ./zblat2.dat
rm -f ?BLAT2.SUMM
OPENBLAS_NUM_THREADS=2 ./sblat2 < ./sblat2.dat
OPENBLAS_NUM_THREADS=2 ./dblat2 < ./dblat2.dat
OPENBLAS_NUM_THREADS=2 ./cblat2 < ./cblat2.dat
OPENBLAS_NUM_THREADS=2 ./zblat2 < ./zblat2.dat
make: *** [tests] Error 2

It looks like I have to use clang to compile (it fails compiling kernels with gcc), so I'm suspecting an incompatibility between the gfortran I have and clang:

fortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC)

clang -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

Any guidance would be appreciated!

[smcallis]

Interesting compiling with just make CC=clang FC=gfortran seems to work fine. Optimization/other flags issue? Stay tuned.

[smcallis]

Seems to be the -ff2c flag that's doing it.

[smcallis]

confirmed, this:

make CC="clang -mmacosx-version-min=10.6" FC="gfortran" FFLAGS="-O2 -fPIC" USE_THREAD=1

Compiles just fine, I'll see if I can get Julia to not pass the -ff2c flag and see where that gets me.

[xianyi]

Hi @smcallis ,

I am not familiar with -ff2c flag. I thinks this issue is about the calling convention, e.g. the return value of cdotc.

Xianyi

[smcallis]

According to the man page:

-ff2c
Generate code designed to be compatible with code generated by
g77 and f2c.

       The calling conventions used by g77 (originally implemented in

f2c) require functions that
return type default "REAL" to actually return the C type
"double", and functions that
return type "COMPLEX" to return the values via an extra argument
in the calling sequence
that points to where to store the return value. Under the
default GNU calling conventions,
such functions simply return their results as they would in GNU
C---default "REAL"
functions return the C type "float", and "COMPLEX" functions
return the GNU C type
"complex". Additionally, this option implies the
-fsecond-underscore option, unless
-fno-second-underscore is explicitly requested.

       This does not affect the generation of code that interfaces with

the libgfortran library.

       Caution: It is not a good idea to mix Fortran code compiled with

-ff2c with code compiled
with the default -fno-f2c calling conventions as, calling
"COMPLEX" or default "REAL"
functions between program parts which were compiled with
different calling conventions will
break at execution time.

       Caution: This will break code which passes intrinsic functions

of type default "REAL" or
"COMPLEX" as actual arguments, as the library implementations
use the -fno-f2c calling
conventions.

So it does indeed twiddle with the calling conventions, I can see how
that'd bite you pretty easily. It was just being passed spuriously through
an old environment variable that I'm not sure how it got set. I removed it
and all is well now, but something to keep in mind if others see unit tests
segfaulting.

On Sun, Nov 11, 2012 at 8:28 PM, Zhang Xianyi [email protected]:

Hi @smcallis https://github.com/smcallis ,

I am not familiar with -ff2c flag. I thinks this issue is about the
calling convention, e.g. the return value of cdotc.

Xianyi

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/156#issuecomment-10276586.

[samueljohn]

@smcallis have you tried to brew tap homebrew-science && brew install openblas
It builds 0.2.4 currently (not 0.2.3).
https://github.com/Homebrew/homebrew-science/blob/master/openblas.rb

There is a tap for julia, too. It's by @staticfloat.

[smcallis]

I got it compiling OK without that flag, and Julia ships with it's own
version they want you to use so I just went with that, thanks though!

On Mon, Nov 12, 2012 at 6:31 AM, Samuel John [email protected]:

@smcallis https://github.com/smcallis have you tried to brew tap
homebrew-science && brew install openblas
It builds 0.2.4 currently (not 0.2.3).
https://github.com/Homebrew/homebrew-science/blob/master/openblas.rb

There is a tap for julia, too. It's by @staticfloathttps://github.com/staticfloat
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/156#issuecomment-10287326.

[samueljohn]

Oh, didn't know Julia vendors openblas.

[smcallis]

They actually pull it from github as part of the compilation and compile it
for you, that way they can eliminate variance from different
versions/compilation options.

On Mon, Nov 12, 2012 at 7:02 AM, Samuel John [email protected]:

Oh, didn't know Julia vendors openblas.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/156#issuecomment-10288450.

[staticfloat]

Just a heads up to you @samueljohn; OpenBLAS 0.2.4 has a bug which has been fixed by the upcoming 0.2.5 (Currently the develop branch), and 0.2.5 passes all Julia tests. I've included a HEAD url in my latest OpenBLAS formula in my julia tap for this.

[25th-engineer]

Interesting compiling with just make CC=clang FC=gfortran seems to work fine. Optimization/other flags issue? Stay tuned.

I tried to compile with the command:

sudo make CC=clang FC=gfortran -j 8

the error didn't occur and finally successed

[martin-frbg]

Well, that error report was nine years ago (and even back then there should have been no reason to tell the compiler to assume unusual calling conventions that make it compatible with the ancient f2c converter)