Bug 186997

Summary: [patch] math/atlas compile error with clang 3.4 on i386
Product: Ports & Packages Reporter: Don Lewis <truckman>
Component: Individual Port(s)Assignee: Brendan Fabeny <bf>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: marino
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Don Lewis freebsd_committer freebsd_triage 2014-02-24 06:00:00 UTC
The port build fails at this point:

cd /usr/ports/math/atlas/work/ATLAS/shared/tune/blas/gemm ; make res/atlas_cacheedge.h pre=d
make dRunFindCE
cd /usr/ports/math/atlas/work/ATLAS/shared/src/blas/gemm ; make dlib
make auxillib dcleanuplib dusergemm
cd /usr/ports/math/atlas/work/ATLAS/shared/src/auxil ; make lib
cd KERNEL ; make -f dMakefile dlib
cc  -fpic -DPIC -DL2SIZE=4194304 -I/usr/ports/math/atlas/work/ATLAS/shared/include -I/usr/ports/math/atlas/work/ATLAS/shared/..//include -I/usr/ports/math/atlas/work/ATLAS/shared/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_FreeBSD -DATL_ARCH_HAMMER -DATL_CPUMHZ=2500 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_3DNow -DATL_GAS_x8632  -DATL_NCPU=2 -D_THREAD_SAFE -D_REENTRANT -DATL_UCLEANM -DATL_UCLEANN -DATL_UCLEANK -DATL_BETA=0 -c -x assembler-with-cpp ATL_dupMBmm0_4_0_b0.c
ATL_dupMBmm0_4_0_b0.c:1633:9: error: ambiguous instructions require an explicit suffix (could be 'subb', 'subw', 'subl', or 'subq')
        sub $1, 36 -4(%esp)
        ^
ATL_dupMBmm0_4_0_b0.c:1648:9: error: ambiguous instructions require an explicit suffix (could be 'subb', 'subw', 'subl', or 'subq')
        sub $1, 36 -4 -4 -4(%esp)
        ^
*** Error code 1

Stop.
make[9]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/src/blas/gemm/KERNEL
*** Error code 1

Stop.
make[8]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/src/blas/gemm
*** Error code 1

Stop.
make[7]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/src/blas/gemm
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/tune/blas/gemm
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/tune/blas/gemm
*** Error code 1

make[5]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/tune/blas/gemm
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/math/atlas/work/ATLAS/shared/bin
ERROR 639 DURING CACHE EDGE DETECTION!!.

Fix: 

The following patch fixes the problem for me.  The MM and NN operands are
32-bit wide memory locations on stack on i386 but the patch should work
because, subq is #defined to be subl earlier in ths file for i386.

This patch is untested on amd64, but I think it should also do the right
thing because MM and NN are CPU registers.
How-To-Repeat: 
Attempt to build math/atlas port with clang 3.4 on 11.0-CURRENT i386.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2014-02-24 06:00:07 UTC
Responsible Changed
From-To: freebsd-ports-bugs->bf

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Don Lewis freebsd_committer freebsd_triage 2014-02-26 05:39:33 UTC
Not sure what happened to the patch.  Here it is again:

--- tune/blas/gemm/CASES/ATL_dmm4x1x90_x87.c.orig       2011-05-14 10:34:10.000000000 -0700
+++ tune/blas/gemm/CASES/ATL_dmm4x1x90_x87.c    2014-02-23 12:58:36.000000000 -0800
@@ -1581,7 +1581,7 @@
         lea     0(pAE,lda,4), pAE
    #endif
 #endif
-        sub     $1, MM
+        subq    $1, MM
         jnz     MLOOP
 
         sub     incAn, pA0
@@ -1596,7 +1596,7 @@
         add     ldb, pB0
         prefetcht0      256(pB0,ldb,2)
         prefetcht0      320(pB0,ldb,2)
-        sub     $1, NN
+        subq    $1, NN
         jnz     NLOOP
 
 DONE:
Comment 3 John Marino freebsd_committer freebsd_triage 2014-08-14 23:39:23 UTC
no point, port is not staged and will be removed in two weeks.  closing.
Comment 4 Don Lewis freebsd_committer freebsd_triage 2014-08-17 16:09:53 UTC
(In reply to John Marino from comment #3)
> no point, port is not staged and will be removed in two weeks.  closing.

Don't be too hasty, see:

Bug 192744 - [stage][patch] math/atlas: STAGEify, fix tmpfile leak during build
Comment 5 Don Lewis freebsd_committer freebsd_triage 2014-08-18 05:56:45 UTC
Just for the record, I am not able to reproduce this problem when compiling with clang 3.4.1.