From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8FD42A034F; Fri, 12 Nov 2021 14:08:41 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21E02410E3; Fri, 12 Nov 2021 14:08:41 +0100 (CET) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by mails.dpdk.org (Postfix) with ESMTP id BD98340692 for ; Fri, 12 Nov 2021 14:08:39 +0100 (CET) Received: by mail-lf1-f41.google.com with SMTP id p16so22263225lfa.2 for ; Fri, 12 Nov 2021 05:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=Ni0ILnWj9/vnNFu7blDUizglwnYE6u//hBR6t/GPUdk=; b=LGv625qMMfuuvDK0TSC0Nzb8Pqm0+eVbWevz+sk9pHcW4f6och4gAe4f90ALPhw4dY sF2M4cDP6wRcovfW6IlQRqEvLJQ/7tBrC23BIt1FFGxAnrRTsz4qU3PG9eFEnHpnJIhM wY7g9SwwMAMnoM2eH5NpC2HlUDKrB9WNJvDaZpmUZu345vPnJGz6RXWWXibm3JUwtf/0 X+93OH93RGgWwvmexeYUjkRYpggXawtgJa0pxKDtnmdcvgIi4IHyJalVbygpW0OBAWR7 lYGa2q7AZDTOPJtAYTJpnYfyqZujN1ilQXp6acyj9+bZHvisZcAsVWBSsTvuv5xuJNrD xjJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=Ni0ILnWj9/vnNFu7blDUizglwnYE6u//hBR6t/GPUdk=; b=T4uYjbly1yy05dEKWSfxXLOr3eH7w8/lNraXeCW+oUwuLmz9eFhb8nfg4BeMXeBfNe 4Jm3YEEIH51e06U3O++uBXJdAibavaylXS44ghBlWTBAYBH64ZZuzxJ0v1RUJgM/RwTv oYk9jbh3UYbs6OkUfywiMSdAifcV2ZxQrP75rtAKehinRpshEXLsX9WXUthrwpNYvfsK 7VV0ofTlzY8/ALf5Fj2isuXjMqINPzZEqVnXfXI8aLwTZJwHbrQvflFxL+ZlrxqMC7TF rOy5tFhLuvFlgloQmFTNPUh9jDTWVwqQSP5iCdeOGezyIdC2oc5jeMTcrQM5NQEM54nW sW4Q== X-Gm-Message-State: AOAM530KU5/LMigsCj3f+EBO6Q0MZby9pLf0s3GCr9N9OPMPiZLhqURT wE6+olf9HHWjjy4sg84ynNBrUcReLdQ= X-Google-Smtp-Source: ABdhPJxwAsebjP0Sww1jw33kI8UDsdL1HdohRLI83eCOIwUjgN4skku8rWoelIMRoRA9NZeiew6rsQ== X-Received: by 2002:a19:ee01:: with SMTP id g1mr14037453lfb.44.1636722519007; Fri, 12 Nov 2021 05:08:39 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id i18sm562412lfe.186.2021.11.12.05.08.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 05:08:38 -0800 (PST) Date: Fri, 12 Nov 2021 16:08:37 +0300 From: Dmitry Kozlyuk To: dev@dpdk.org, Ferruh Yigit , Bruce Richardson , Leyi Rong Cc: David Marchand , Akhil Goyal Subject: buildtools/binutils-avx512-check.sh Message-ID: <20211112160837.131994aa@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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') 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 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. What to others think?