From nobody Sat Aug 31 07:16:47 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WwmXy2Wv4z5TmBp; Sat, 31 Aug 2024 07:16:50 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WwmXy1yK1z4hsC; Sat, 31 Aug 2024 07:16:50 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725088610; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zbSe2hJKwshLEKf0c6MHWRgm8tjhijUsYBLo4eqA3Ko=; b=SoM9gIAAMPul4qDP1skFLcMwzbWpbbw59tQD8RFPsBk4Qg9jxn3RRWXqUHl671r8+aT5qZ FaYmEHBsW0CtO0f88qMunQxgtfsL+PHuYljLrGEaV/QbZzrvvkJGMkQUmO994CtlozRrxm 9w1JIQ7r2aATuO+qymeo5hpbawyh69N2KN+FwL1Ogd4xcanOMA5uZJ8YY0Vps4IItIKpHD 1/3R+AnNLPl0nSiC2QEFNgssQgKQW5OjtXxboFQXPGDvd6Yb8ZlNYwZ7FP6vd2V/HN1sRp MPfIRgaS1Kkxt+ymQmXhkSkzNJygYLpCrkRyGAw4RspwT+hayUfBj868weyNcQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725088610; a=rsa-sha256; cv=none; b=GM4yVmmy7AtJN48T40HhZg7WPoBITqwFKPF9l+yHK69XBJrF6J0E6kCMdzAtkh+WB+rfAa rRbW+L+HqUNGAbzztcviDvyWLcj3mGZAcbUrTRC0Sq4wYl/0FgJx4uwhp+HWVyzSqtXDX8 +3QYuacJ6zVnDiaIujiEtdYpZsKjklS26lGumeZNY1XZOWOrzC7/escGWDBp1TSqY84Xh2 Gj0ucRab+C95gJBaJSlA52L+vi7hBKxuA48fpzX0AyFEhwkVCKQyRAJx8vjoG9SJmFlGS8 pfq8CSAyMJQmssW6gMKxTun1mc6W11bEhwkEWFsggRIaTCtyJk201/82Shv3jQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725088610; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zbSe2hJKwshLEKf0c6MHWRgm8tjhijUsYBLo4eqA3Ko=; b=mAkKaNXMDKiQN7jou3gh3tOOYAqhjKQ3F9D6mVM6+PZqs3fVwa7e2FK3tRBK96FeQsgAtd IN4CaG4Fw/dlUpmeQG9EUwYiAEw7H/oOu8zKinjJ1MmGxiVWiL+vo3M2wDyapo7N6L1FnX zrIcprcSpBzc8AsqfSfymBJ8BfAAmBj0fLrG/b44wB6XyxD3LijiGMLBh0kMBCelGIxlhZ 6PwEi5f9d3bOHOUBD+jIQ3YNC+55d6Ddpi5Dpxw1ufg5zT095En8Q8ycl682L+1WgJbhsb gdgDfc45EF7Gmt0Flv40prkm+UfD9trFW4LOoMFir3FEMxnl2jIfJ0+k53Bbog== Received: from [IPV6:2001:67c:14a0:5fe0:686e:135e:76e3:3f4e] (unknown [IPv6:2001:67c:14a0:5fe0:686e:135e:76e3:3f4e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WwmXx2vZcz1SW1; Sat, 31 Aug 2024 07:16:49 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> Date: Sat, 31 Aug 2024 09:16:47 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@FreeBSD.org Subject: Re: For an armv7 context, /usr/local/llvm1[789]/lib/clang/1[789]/include/arm_bf16.h does not exist: one thing blocking a firefox build via llvm1[78] To: Mark Millard , FreeBSD Mailing List , FreeBSD ARM List Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 31.08.2024 8:29, Mark Millard wrote: > On Aug 30, 2024, at 22:05, Mark Millard wrote: > >> On Aug 30, 2024, at 21:26, Mark Millard wrote: >> >>> On Aug 30, 2024, at 20:33, Mark Millard wrote: >>> >>>> [Subject was retitled.] >>>> >>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: >>>> >>>>> What my test-of-building got was: No include file found and >>>>> no OFlags::TMPFILE found (OFlags:: was found, TMPFILE in OFlags:: was not): >>>>> >>>>> In file included from /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.c:43: >>>>> In file included from /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.h:3434: >>>>> /usr/local/llvm17/lib/clang/17/include/arm_neon.h:37:10: fatal error: 'arm_bf16.h' file not found >>>>> 37 | #include >>>>> | ^~~~~~~~~~~~ >>>>> . . . >>>>> >>>>> error[E0599]: no associated item named `TMPFILE` found for struct `backend::fs::types::OFlags` in the current scope >>>>> --> /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/syscalls.rs:144:32 >>>>> | >>>>> 144 | if oflags.contains(OFlags::TMPFILE) && crate::backend::if_glibc_is_less_than_2_25() { >>>>> | ^^^^^^^ associated item not found in `OFlags` >>>>> | >>>>> ::: /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/types.rs:203:1 >>>>> | >>>>> 203 | / bitflags! { >>>>> 204 | | /// `O_*` constants for use with [`openat`]. >>>>> 205 | | /// >>>>> 206 | | /// [`openat`]: crate::fs::openat >>>>> ... | >>>>> 333 | | } >>>>> 334 | | } >>>>> | |_- associated item `TMPFILE` not found for this struct >>>>> | >>>>> . . . >>>>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info) >>>>> >>>>> . . . >>>>> >>>>> error[E0599]: no associated item named `TMPFILE` found for struct `backend::fs::types::OFlags` in the current scope >>>>> --> /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/syscalls.rs:207:32 >>>>> | >>>>> 207 | if oflags.contains(OFlags::TMPFILE) && crate::backend::if_glibc_is_less_than_2_25() { >>>>> | ^^^^^^^ associated item not found in `OFlags` >>>>> | >>>>> ::: /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/types.rs:203:1 >>>>> | >>>>> 203 | / bitflags! { >>>>> 204 | | /// `O_*` constants for use with [`openat`]. >>>>> 205 | | /// >>>>> 206 | | /// [`openat`]: crate::fs::openat >>>>> ... | >>>>> 333 | | } >>>>> 334 | | } >>>>> | |_- associated item `TMPFILE` not found for this struct >>>>> | >>>>> . . . >>>>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info) >>>>> >>>>> . . . >>>>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info) >>>>> >>>>> For more information about this error, try `rustc --explain E0599`. >>>>> error: could not compile `rustix` (lib) due to 2 previous errors >>>>> >>>>> >>>>> For reference: >>>>> >>>>> # uname -apKU >>>>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #8 main-n271819-5cbb98c8259c-dirty: Fri Aug 23 22:06:47 PDT 2024 root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500023 1500023 >>>>> >>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ >>>>> 87a38a839ab8 (HEAD -> main, freebsd/main, freebsd/HEAD) net-im/dissent: update package description >>>>> Author: Jan Beich >>>>> Commit: Jan Beich >>>>> CommitDate: 2024-08-24 18:30:01 +0000 >>>>> branch: main >>>>> merge-base: 87a38a839ab83c2def100a0975a7afb29e873cf2 >>>>> merge-base: CommitDate: 2024-08-24 18:30:01 +0000 >>>>> n674987 (--first-parent --count for merge-base) >>>>> >>>>> But firefox was updated to use: nss>=3.103:security/nss to match what was >>>>> available. >>>> >>>> >>>> Using devel/llvm18 instead got the same. >>>> >>>> Looking inside even a /usr/local/llvm19/lib/clang/19/include/ >>>> also shows the arm_bf16.h file is not present. By contrast, >>>> for an aarch64 context: >>>> >>>> # file /usr/local/llvm19/lib/clang/19/include/arm_bf16.h >>>> /usr/local/llvm19/lib/clang/19/include/arm_bf16.h: C source, ASCII text >>>> >>>> Looking quickly at more llvm* shows: >>>> >>>> # grep -r arm_bf16 /usr/ports/devel/llvm1*/ | more >>>> /usr/ports/devel/llvm11/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h >>>> /usr/ports/devel/llvm12/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h >>>> /usr/ports/devel/llvm13/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h >>>> /usr/ports/devel/llvm14/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>> /usr/ports/devel/llvm15/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: `arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: `arm_bf16.h` immediately before their own typedef: >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: #include >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: Since `arm_bf16.h` is very likely supposed to be the one true place where >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << "#include \n"; >>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << "#include \n"; >>>> /usr/ports/devel/llvm16/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>> /usr/ports/devel/llvm17/Makefile:_BE_INCS_AArch64= arm_bf16.h arm_sme_draft_spec_subject_to_change.h >>>> /usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64= arm_bf16.h >>>> /usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64= arm_bf16.h >>>> >>>> llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more). >>>> llvm1[789] do not. >>>> >>>> I wonder if: >>>> >>>> https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=778e212f234a825c5e19612df4be2e8f838cb024 >>>> >>>> doing: >>>> >>>> -_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>> +_BE_INCS_ARM= arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>> >>>> was correct. I'll note that in an armv7 context: >>>> >>>> # find /usr/local/*/gcc14/ -name arm_bf16.h -print >>>> /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd15.0/14.2.0/include/arm_bf16.h >>>> >>>> suggesting that gcc14 considers the file as not aarch64 specific but >>>> as armv7 compatibile. >>> >>> I got that wrong! arm vs. aarch64 have different source files with the >>> same name (under different paths): >>> >>> gcc/gcc/config/arm/arm_bf16.h has guard test: #ifndef _GCC_ARM_BF16_H >>> gcc/gcc/config/aarch64/arm_bf16.h has guard test: #ifndef _AARCH64_BF16_H_ >>> >>> (More content is different.) >> >> As for llvm*: >> >> clang/lib/Basic/Targets/ARM.cpp has: >> >> if (HasBFloat16) { >> Builder.defineMacro("__ARM_FEATURE_BF16", "1"); >> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1"); >> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1"); >> } >> >> clang/lib/Basic/Targets/AArch64.cpp has: >> >> if (HasBFloat16) { >> Builder.defineMacro("__ARM_FEATURE_BF16", "1"); >> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1"); >> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1"); >> } >> >> which suggests bf16 support has 32-bit support (even if it is armv8 >> 32-bit). Looking for AArch32 state in: >> >> DDI0487K_a_a-profile_architecture_reference_manual.pdf >> >> it says (via the AArch32 column of a table): >> >> BF16 Supported if FEAT_AA32BF16 is implemented. >> >> Looks to me like the removal of arm_bf16.h for llvm target ARM >> was incorrect. >> >>>> So I've put arm_bf16.h back into the llvm18 test context and sometime >>>> after 3 hrs I should be able to report on a firefox build attempt with >>>> the change (I hope). >>> >> > > So, it no longer failed for amd_bf16.h being missing. > > But it still has the lack-of OFlags::TMPFILE problem that stops the build. > > See lang/rust/files/armv7/patch-vendor_rustix_src_backend_libc_fs_syscalls.rs for inspiration. Unfortunately the exact patch depends on the rustx version, which changes a lot at this place. Michal