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]
- Reply: Mark Millard : "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]"
- In reply to: Mark Millard : "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]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 03 Sep 2024 18:12:59 UTC
On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: > On Aug 30, 2024, at 21:26, Mark Millard <marklmi@yahoo.com> wrote: > > > On Aug 30, 2024, at 20:33, Mark Millard <marklmi@yahoo.com> wrote: > > > >> [Subject was retitled.] > >> > >> On Aug 30, 2024, at 16:24, Mark Millard <marklmi@yahoo.com> wrote: > >> > >>> What my test-of-building got was: No <arm_bf16.h> 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 <arm_bf16.h> > >>> | ^~~~~~~~~~~~ > >>> . . . > >>> > >>> 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 <jbeich@FreeBSD.org> > >>> Commit: Jan Beich <jbeich@FreeBSD.org> > >>> 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 <arm_bf16.h> > >> /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 <arm_bf16.h>\n"; > >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << "#include <arm_bf16.h>\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. The commit to the port simply refects changes upstream which made arm_br16.h aarch64-only. It was done in a massive commit (a70cf56d20b956) so may well have been wrong and no one notices because they always build all the backends. -- Brooks