[atlas-devel] 3.9.46 on 64-bit Windows

[Andrey Z. <aa...@al...>]

Hi all,

I had some success with ATLAS on 64-bit Windows. The goal was to build
a single-threaded version under Cygwin (XCC=gcc) using the Cygwin-
packaged MinGW gcc (ICC etc=x86_64-w64-mingw32-gcc) and gfortran
(F77=x86_64-w64-mingw32-gfortran).

I did most of the work on 3.8.4 and later switched to 3.9.46, so you
may already be aware of some of these issues.

The main problem is the ABI: the assembly routines in ATLAS follow the
System V ABI, while MinGW uses the different Microsoft ABI. I think the
solution for this is to compile all kernels with -mabi=sysv and to
decorate all prototypes of kernel routines in the rest of ATLAS with
__attribute__((__sysv_abi__)). The entire library can't be compiled
with -mabi=sysv since that breaks all calls to libc (e.g. fprintf in
the tuning routines), and it wouldn't be compatible with other Windows
programs.

I didn't do this, but instead I disabled the assembler after platform
detection and compiled with -Si archdef 0 since some of the defaults
rely on assembly routines. With the following tweaks I got a working
build on a P4 and another user got a working build on some kind of Core
machine by running make repeatedly as there were puzzling intermittent
errors.


Tweaks:

- In CONFIG/src/{config,atlconf_misc}.c enlarged command line buffers.
  (7 times "x86_64-w64-mingw32-" and a few flags makes a long string).

- In CONFIG/src/Makefile added -static where backend/*.f files are
  compiled with F77. This is a workaround for Cygwin install not
  adding "/usr/x86_64-w64-mingw32/sys-root/mingw/bin" to $PATH, so
  Fortran binaries can't find the libgfortran DLL and don't work.
  (It's a bad idea to do this generally as -static breaks the binaries
  on some other platforms, but may be worth a note in the docs.)

- Disabled the MinGW wrappers, as Cygwin-packaged MinGW compilers
  understand Cygwin paths (though the binaries they output don't).

- Disabled appending any -m32/-m64 flags for XCC. It generally
  doesn't matter what the binary format of XCC output is as long as it
  runs, so whatever the compiler defaults to should be fine.
  (In 3.9.46 you add -m32, which is effectively the same in Cygwin.)

- In SpewMakeInc.c made it always pick ICC for goodgcc (I think I did
  this for a different platform where the compiler was called "gcc44"
  and didn't get picked).

- In probe_OS.c made it detect Windows by the string "MINGW" in
  addition to "WIN". (This isn't for Cygwin, but for MSYS - a 32-bit
  binary builds nicely there.)

- In tune/sysinfo/emit_buildinfo.c in FixString used isspace(ln[i]) to
  strip trailing whitespace so that '\r' is included. (This is for MSYS
  again, but might also apply to some Cygwin configurations.)

- With the attached patch, made some MinGW-compiled tuning binaries
  output to a relative path instead of an absolute Cygwin path that
  they don't understand. I made a new directory to make sure that they
  didn't overwrite anything, but you probably have a better idea where
  those files can be placed safely.

- In CONFIG/src/backend/{probe_*,archinfo_x86}.c decorated prototypes
  for asm_probe, do_vsum and do_cpuid with
  __attribute__((__sysv_abi__)), made CONFIG/src/probe_*.c append
  -DATL_USE64BITS when it ran the probes, and changed configure to
  use ICC=x86_64-w64-mingw32-gcc during the configure stage (by default
  it uses ICC=XCC=gcc). This made the probes run in 64-bit mode and
  correctly detect ATL_GAS_x8664, but, since I disabled the assembler
  afterwards, this didn't affect the build.


Hope this is useful.
- Andrey