On Fri, Nov 12, 2021 at 04:08:37PM +0300, Dmitry Kozlyuk wrote:
> Hello,
>
> I'm working on improvement of Linux-to-Windows cross-compilation using MinGW.
> Currently there is c_args = '-mno-avx512f' in config/x86/cross-mingw, however,
> 1) baseline meson 0.49.2 doesn't like it*
> 2) it should be in machine_args because they are checked in various places
> 3) I don't like disabling AVX512F if there is really no issue**
> So I started looking at the subject script.
>
> * '-mno-avx512f' should be ['-mno-avx512f'], but then the build of lib/net
> breaks, because meson 0.49.2 and 0.57.0 (native Windows baseline)
> order compiler arguments differently.
>
> ** There was a .seh_savemm bug with MinGW that -mno-avx512f was trying to fix,
> but I believe that -fno-asynchronous-unwind tables was the final solution.
> However, AVX512 support is still broken for native MinGW builds, see below.
>
> First question. In config/x86/meson.build we have:
>
> # get binutils version for the workaround of Bug 97
> if not is_windows
> binutils_ok = run_command(binutils_avx512_check)
> if binutils_ok.returncode() != 0 and cc.has_argument('-mno-avx512f')
> machine_args += '-mno-avx512f'
> warning('Binutils error with AVX512 assembly, disabling AVX512
> support')
> endif
> endif
>
> This is a GNU binutils bug and if I understand correctly,
> it doesn't affect builds that use LLVM binutils (FreeBSD and Windows+clang).
> The script also uses ${AS:-as} and objdump, that may be missing.
> Consequently, AVX512F may be disabled for LLVM-based builds
> because GNU toolchain has a bug or is just absent:
>
> root@freebsd:/tmp/dpdk # meson build
> [...]
> config/x86/meson.build:9: WARNING: Binutils error with AVX512 assembly,
> disabling AVX512 support
> [...]
>
> root@freebsd:/tmp/dpdk # uname -r
> 13.0-RELEASE
>
> root@freebsd:/tmp/dpdk # ./buildtools/binutils-avx512-check.sh
> ./buildtools/binutils-avx512-check.sh: as: not found
> ./buildtools/binutils-avx512-check.sh: objdump: not found
> vpgatherqq displacement error with as
>
> Probably the script output and its check should be enhanced
> to distinguish between its failure and success with negative answer?
> Or should the check be done under a condition like this?
>
> if not is_windows and (is_linux or cc.get_id() == 'gcc')
>
That seems reasonable. At least in this case, the failure mode is fairly
safe as it always gives a correct build, but if it can be improved I have
no objection.
>
> The next question is the preferred approach to fix things for Windows.
> Current status:
> 1) MinGW 8.1.0 on Windows: buggy
> 2) MinGW 7.0.0 on Linux: OK
> 3) LLVM on Windows: OK
>
> One solution is simply state this:
>
> if not is_windows
> binutils_bug_97 = ... # run the script
> elif cc.get_id() == 'gcc'
> binutils_bug_97 = true
The script still needs to be run here. Even in case of gcc, it's only a few
point releases of binutils that cause issues.
> endif
> if binutils_bug_97
> machine_args += '-mno-avx512f'
> warning('...')
> endif
>
> Another one is to make the script portable
> and run it when LLVM is not used, on any OS, including cross builds.
> By the way, $AS and objdump binaries may be overridden in a --cross-file,
> so in this case we should locate them with meson.
Seems reasonable, and easy enough to fix.
> What to others think?
