tuneup crash after proper libgmp build/check/install on Macbookpro11 (Haswell/AVX2) Mavericks

Marc-Olivier Killijian marco.killijian at laas.fr
Fri Feb 7 16:54:31 UTC 2014


Dear colleagues,

In a try to even further optimize GMP for my particular machine, I wanted to use tuneup but failed to do so because the tuneup process "suicides ».

I obtained gmp-5.1.3 from the tar ball at your website.
I compiled it with a mixture of GCC4.8 (from macports) and Clang (for assembling avx2 code) with the following settings.

gcc -v : gcc version 4.8.2 (MacPorts gcc48 4.8.2_0)
clang -v : clang version 3.4 (tags/RELEASE_34/final)
echo $LDFLAGS : -L/usr/lib -L/opt/local/lib
echo $CFLAGS : -Ofast -mavx2 -Wa,-q
these CFLAGS are for being able to assemble avx2 code on OSX, it calls clang for the final compilation of gcc generated assembly code.

./configure --prefix=/path-to-home/sw

make;make check : no error
make install : fine
do my stuff, compile my gmp-based-program (mpz-only) : fine

but ./tuneup :
> Parameters for ./mpn/x86_64/coreinhm/gmp-mparam.h
> Using: CPU cycle counter, supplemented by microsecond getrusage()
> speed_precision 10000, speed_unittime 3.57e-10 secs, CPU freq 2800.00 MHz
> DEFAULT_MAX_SIZE 1000, fft_max_size 50000
> 
> /* Generated by tuneup.c, 2014-02-07, gcc 4.8 */
> 
> #define MOD_1_NORM_THRESHOLD                 0  /* always */
> #define MOD_1_UNNORM_THRESHOLD               0  /* always */
> #define MOD_1N_TO_MOD_1_1_THRESHOLD          3
> #define MOD_1U_TO_MOD_1_1_THRESHOLD          3
> #define MOD_1_1_TO_MOD_1_2_THRESHOLD        10
> #define MOD_1_2_TO_MOD_1_4_THRESHOLD        26
> #define PREINV_MOD_1_TO_MOD_1_THRESHOLD     10
> #define USE_PREINV_DIVREM_1                  1  /* native */
> #define DIV_QR_2_PI2_THRESHOLD              19
> #define DIVEXACT_1_THRESHOLD                 0  /* always (native) */
> #define BMOD_1_TO_MOD_1_THRESHOLD           25
> 
> #define MUL_TOOM22_THRESHOLD                18
> speed_measure() could not get 4 results within 1.0%
>     unsorted         sorted
>   0.000000059400    0.000000047543    is about 0.5%
>   0.000005940       0.000004754
>   0.000005285       0.000004864
>   0.000005238       0.000004920
>   0.000005480       0.000005057
>   0.000006300       0.000005238
>   0.000004754       0.000005285
>   0.000004864       0.000005480
>   0.000004920       0.000005770
>   0.000005057       0.000005940
>   0.000006626       0.000006205
>   0.000006439       0.000006300
>   0.000005770       0.000006348
>   0.000006205       0.000006403
>   0.000006403       0.000006439
>   0.000019948       0.000006483
>   0.000019133       0.000006550
>   0.000007902       0.000006626
>   0.000006483       0.000006709
>   0.000006837       0.000006765
>   0.000007198       0.000006833
>   0.000006348       0.000006837
>   0.000007133       0.000006869
>   0.000006869       0.000007091
>   0.000006709       0.000007096
>   0.000006550       0.000007133
>   0.000007091       0.000007198
>   0.000006765       0.000007559
>   0.000006833       0.000007902
>   0.000007559       0.000019133
>   0.000007096       0.000019948
> [1]    24621 abort      ./tuneup

Running in a debugger (lldb) gives me the following backtrace :
> Process 24871 stopped
> * thread #1: tid = 0xf8ddd, 0x00007fff90ada866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread, stop reason = signal SIGABRT
>     frame #0: 0x00007fff90ada866 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill + 10:
> -> 0x7fff90ada866:  jae    0x7fff90ada870            ; __pthread_kill + 20
>    0x7fff90ada868:  movq   %rax, %rdi
>    0x7fff90ada86b:  jmpq   0x7fff90ad7175            ; cerror_nocancel
>    0x7fff90ada870:  ret

I don’t find any good reason why this happens, so I’m raising this bug report in a hope it may help.

Best regards,
Marc-Olivier Killijian



More information about the gmp-bugs mailing list