OpenBLAS @0.3.25 does not upgrade on macOS High Sierra, Version 10.13.6, because of som assembler problem: suffix or operands invalid for `movq' when cctools is installed with the +xtools variant

[ballapete (Peter "Pete" Dyballa)]

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/compwrap/fc/opt/local/bin/gfortran-mp-12 -m64 -Os -O3 -m128bit-long-double -Wall -frecursive -fno-optimize-sibling-calls -m64 -fPIC -msse3 -mssse3 -fno-tree-vectorize -c -o dgbsvx.o dgbsvx.f
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/.tmp/ccVxPK00.s:154:suffix or operands invalid for `movq'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/.tmp/ccVxPK00.s:277:suffix or operands invalid for `movq'
make[2]: *** [dgbequ.o] Error 1
make[2]: *** Waiting for unfinished jobs....
dgbsvx.f:477:72:

  477 |                COLCND = MAX( RCMIN, SMLNUM ) / MIN( RCMAX, BIGNUM )
      |                                                                        ^
Warning: 'smlnum' may be used uninitialized [-Wmaybe-uninitialized]
dgbsvx.f:397:47:

  397 |      $                   ROWCND, RPVGRW, SMLNUM
      |                                               ^
note: 'smlnum' was declared here
dgbsvx.f:477:72:

  477 |                COLCND = MAX( RCMIN, SMLNUM ) / MIN( RCMAX, BIGNUM )
      |                                                                        ^
Warning: 'bignum' may be used uninitialized [-Wmaybe-uninitialized]
dgbsvx.f:396:44:

  396 |       DOUBLE PRECISION   AMAX, ANORM, BIGNUM, COLCND, RCMAX, RCMIN,
      |                                            ^
note: 'bignum' was declared here
sgesvdq.f:1375:72:

 1375 |       IF ( CONDA ) RWORK(1) = SCONDA
      |                                                                        ^
Warning: 'sconda' may be used uninitialized [-Wmaybe-uninitialized]
sgesvdq.f:442:42:

  442 |       REAL        BIG, EPSLN, RTMP, SCONDA, SFMIN
      |                                          ^
note: 'sconda' was declared here
sgesvdq.f:606:72:

  606 |      $                               LWRK_SORMQR )
      |                                                                        ^
Warning: 'lwrk_sgeqp3' may be used uninitialized [-Wmaybe-uninitialized]
sgesvdq.f:435:29:

  435 |      $            LWRK_SGEQP3,  LWRK_SGEQRF, LWRK_SORMLQ, LWRK_SORMQR,
      |                             ^
note: 'lwrk_sgeqp3' was declared here
sgesvdq.f:591:72:

  591 |                  MINWRK = N + MAX( LWQP3, LWCON, LWSVD, LWORQ )
      |                                                                        ^
Warning: 'lworq' may be used uninitialized [-Wmaybe-uninitialized]
sgesvdq.f:436:66:

  436 |      $            LWRK_SORMQR2, LWLQF, LWQRF, LWSVD, LWSVD2, LWORQ,
      |                                                                  ^
note: 'lworq' was declared here
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/OpenBLAS-0.3.25/lapack-netlib/SRC'

[ballapete (Peter "Pete" Dyballa)]

Main.log from High Sierra 10.13.6

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

suffix or operands invalid for `movq'

I found a couple occurrences of this error on Google which were blamed on "MacPorts" with the suggestion that it should be uninstalled, so that's obviously not a helpful suggestion in our case.

One of those reports also observed the problem with Homebrew when a gcc symlink had been created in the path. Do you have /opt/local/bin/gcc, for example created by using sudo port select gcc? If so, try selecting none. Or do you have /usr/local/bin/gcc? If so, delete it and anything else in /usr/local. And then of course clean and try again.

[jmroot (Joshua Root)]

MacPorts gcc uses the cctools assembler, which uses clang if available. So which MacPorts clang ports you have installed could influence this.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

One of those reports also observed the problem with Homebrew when a gcc symlink had been created in the path. Do you have /opt/local/bin/gcc, for example created by using sudo port select gcc?

No Homebrew, /opt/local/bin/gcc. Since I have

Name       Selected        Options
====       ========        =======
clang      mp-clang-16     mp-clang-15 mp-clang-16 mp-clang-17 none
gcc        mp-gcc12        mp-gcc12 none
llvm       mp-llvm-16      mp-llvm-15 mp-llvm-16 mp-llvm-17 none
mpi        none            none

I'll try again with mp-clang-17!

[ballapete (Peter "Pete" Dyballa)]

Replying to jmroot:

MacPorts gcc uses the cctools assembler, which uses clang if available. So which MacPorts clang ports you have installed could influence this.

And I have installed this one:

  cctools @949.0.1_3+xtools (active)

which should better be +xcode or +llvm-17? The default

[+]llvm10: Use llvm-10 for libLTO, llvm-mc, llvm-size, and llvm-nm

looks a bit strange…

[ballapete (Peter "Pete" Dyballa)]

With mp-clang-17 and cctools+xtools the build breaks with the same report. I'll try cctools+llvm-17 – which need an update from time to time (and I think clang/llvm do not report this need, they just install without any input from me).

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

which should better be +xcode or +llvm-17? The default

[+]llvm10: Use llvm-10 for libLTO, llvm-mc, llvm-size, and llvm-nm

looks a bit strange…

The default selected by MacPorts is supposed to be the right one to use.

[ballapete (Peter "Pete" Dyballa)]

No. Because: The following dependencies will be installed: llvm-10.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

The default selected by MacPorts is supposed to be the right one to use.

The default is with stone old llvm-10.

[kencu (Ken)]

Replying to ballapete:

Replying to jmroot:

MacPorts gcc uses the cctools assembler, which uses clang if available. So which MacPorts clang ports you have installed could influence this.

And I have installed this one:

  cctools @949.0.1_3+xtools (active)

This variant of cctools is completely inappropriate for anyone to use, except for someone who is interested in trying out Iain's experimental software to make clang-7 work on PowerPC.

(Which is why I argued against this variant being added to macports in the first place.)

[ballapete (Peter "Pete" Dyballa)]

The error also happens when building with configure.cc=gcc-mp-12 configure.fc=gfortran-mp-12 or configure.cc=gcc-mp-13 configure.fc=gfortran-mp-13.

[kencu (Ken)]

until you change your cctools variant to something supported by MacPorts, nobody can help you.

use macports default variant.

[ballapete (Peter "Pete" Dyballa)]

It built now with:

The following ports are currently installed:
  cctools @949.0.1_3+xcode (active)
  cctools @949.0.1_3+xtools

So it's not necessary to install some old version of LLVM.

[kencu (Ken)]

OK. The +xcode variant also works, on 10.13, apparently.

still, use macports defaults unless you know what you are doing, otherwise you will run into troubles like this.