OpenBLAS @0.3.6: error: 32-bit absolute addressing is not supported in 64-bit mode

[kencu (Ken)]

This error comes when I try to build the new "default version" in my current 10.6.8 system. Building the +native version still works correctly.

Must be something about the forced processor spec that my system is not liking.

Full log attached.

/opt/local/bin/clang-mp-5.0 -c -O3 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DNO_AVX2 -DNO_AVX512 -DSMP_SERVER -DMAX_CPU_NUMBER=4 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"1\" -DASMNAME=_ssymv_U -DASMFNAME=_ssymv_U_ -DNAME=ssymv_U_ -DCNAME=ssymv_U -DCHAR_NAME=\"ssymv_U_\" -DCHAR_CNAME=\"ssymv_U\" -DNO_AFFINITY -I.. -UDOUBLE  -UCOMPLEX -UCOMPLEX -UDOUBLE -ULOWER ../kernel/x86_64/symv_U_sse.S -o ssymv_U.o
../kernel/x86_64/symv_U_sse.S:425:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCH PREFETCHSIZE(%rbx)
 ^
../kernel/x86_64/symv_U_sse.S:444:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCH PREFETCHSIZE(%r13)
 ^
../kernel/x86_64/symv_U_sse.S:469:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCH PREFETCHSIZE(%rbx, %rcx, 1)
 ^
../kernel/x86_64/symv_U_sse.S:510:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCH PREFETCHSIZE(%rbp)
 ^
../kernel/x86_64/symv_U_sse.S:529:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCHW PREFETCHSIZE(%r14)
 ^
../kernel/x86_64/symv_U_sse.S:554:2: error: 32-bit absolute addressing is not supported in 64-bit mode
 PREFETCH PREFETCHSIZE(%rbp, %rcx, 1)
 ^
make[1]: *** [ssymv_U.o] Error 1

[kencu (Ken)]

perhaps this Wikipedia quote is helpful

Intel 64 (Intel's x86-64 implementation) is not supported by Yonah. However, Intel 64 support is integrated in Yonah's successor, the mobile version of Core 2, code-named Merom.

[kencu (Ken)]

So if I read that correctly (chime in, anyone who knows) Yonah would be 32bit only, but if OpenBLAS is building 64bit, then the lowest processor would be Core2.

[kencu (Ken)]

branching to core2 on 10.6 based on os.arch did not work, unfortunately...

[NicosPavlov]

Oh, I was just answering saying that your description was making quite some sense, which would have meant that we should make a condition depending on the architecture, such as:

if {${os.major} == 10} { 
    if {${os.arch} eq "i386"]} {
        set blas_arch "YONAH"
    } else { #YONAH does not support 64-bit, see #58528
        set blas_arch "CORE2"
    }
} 

It the error identical if you set to CORE2? I did not check with the buildbot yet, but as both i386 and x86_64 packages are available on the servers, it would mean that there is a difference that might be informative.

[kencu (Ken)]

I thought that exact thing would work -- it should work! Let me try it again, maybe I didn't enter it correctly.

[NicosPavlov]

Just in case, I attach a patch that contains the change, along with the case for universal builds, for the sake of completeness in case using CORE2 actually works.

[kencu (Ken)]

I think the problem is branching on os.arch. According to the guide, that returns either i386 or powerpc. So if we want 32bit vs 64bit, I think we have to branch on build.arch.

For the record, CORE2 does work on 10.6.8 64bit. YONAH doesn't.

So making progress maybe.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I think the problem is branching on os.arch. According to the guide, that returns either i386 or powerpc. So if we want 32bit vs 64bit, I think we have to branch on build.arch.

That is correct, except that that will only work for non-universal builds. For universal builds, you'll probably have to use the facilities of the muniversal portgroup to pass different settings to each arch -- which I see the portfile already does.

[NicosPavlov]

Revised patch with correct use of build_arch

[NicosPavlov]

So then the revised patch should be correct, isn't it? I should have seen it from the start, the part for universal builds was already using that variable in other places...

[rmottola (Riccardo)]

I have the same issue with OpenBLAS on 10.6! Which portfile should be patched? I tried to apply the patch to the OpenBLAS portfile and it looks so different that it doesn't apply. Maybe I am picking up the wrong one?

/opt/local/var/macports/registry/portfiles/OpenBLAS-0.3.5_1

[NicosPavlov]

The Portfile found in registry is not the latest version, so that the patch does not apply cleanly. You can find the latest Portfile (that your system use for install) at

/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/math/OpenBLAS

However, the simplest way to use a locally modified Portfile may be to follow the instructions to ​create a local repository. It is also possible to retrieve the content of the Portfile (instead of going to the file tree structure) with

port cat OpenBLAS

Please let me know if the patch fixes your issue. If so, I'll commit it to the main repository.

[kencu (Ken)]

unfortunately the patch is not fixing the build on 10.6.8 at least...

I'll work on this over the next while.

[rmottola (Riccardo)]

I think this bug is a duplicate of #58832 ... and it still bites me on 10.6 and 10.7

[rmottola (Riccardo)]

+native doesn't help for me on 10.7

[NicosPavlov]

This might be a naive (or even dumb) question, but considering that some instructions are not supported in 64-bit builds with theses OSes, does it work to build the library in 32-bit?

[kencu (Ken)]

I will get around to fixing this - just too easy to hold at the last version so haven't bothered...

Let me try building it outside MacPorts and see what's going on here.

Riccardo, you can fix this! I could use some help!

[kencu (Ken)]

see 58832 where there is a fix for this. Just not sure whether to fix it or wait for the next version to come out, that I think has a fix already in git master for this.

[kencu (Ken)]

So the issue in this ticket is actually different than 58832, and seems to be that the forced processor, "YONAH", doesn't exist in that file, and so there is no macro to define it properly, ergo the unreplaced PREFETCH. Just spitballin', it looks like it should be the same as CORE2, but that's a WAG at the moment:

#ifdef ATOM
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 12)
#endif

#ifdef CORE2
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 12)
#endif

#if defined(PENRYN) || defined(DUNNINGTON)
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 12)
#endif

#if defined(NEHALEM) || defined(SANDYBRIDGE)  || defined(HASWELL) || defined(ZEN) || defined (SKYLAKEX)
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 12)
#endif

#ifdef PENTIUM4
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 20)
#endif

#ifdef OPTERON
#define PREFETCH	prefetch
#define PREFETCHW	prefetchw
#define PREFETCHSIZE	(16 * 8)
#define movsd		movlps
#endif

#if defined(BARCELONA) || defined(SHANGHAI) || defined(BOBCAT) || defined(BARCELONA_OPTIMIZATION)
#define PREFETCH	prefetch
#define PREFETCHW	prefetchw
#define PREFETCHSIZE	(16 * 16)
#endif

#ifdef NANO
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 24)
#endif

#ifdef GENERIC
#define PREFETCH	prefetcht0
#define PREFETCHW	prefetcht0
#define PREFETCHSIZE	(16 * 20)
#endif

[kencu (Ken)]

[7beaccfb4e499312fb95e5c7af7becd6b3c9cf46/macports-ports]