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]
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.toolchain,gmane.os.freebsd.devel.ports,gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On Sep 3, 2024, at 12:09, Mark Millard <[email protected]> wrote: > On Sep 3, 2024, at 11:12, Brooks Davis <[email protected]> wrote: > >> On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: >>> On Aug 30, 2024, at 21:26, Mark Millard <[email protected]> wrote: >>> >>>> On Aug 30, 2024, at 20:33, Mark Millard <[email protected]> wrote: >>>> >>>>> [Subject was retitled.] >>>>> >>>>> On Aug 30, 2024, at 16:24, Mark Millard <[email protected]> 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 <[email protected]> >>>>>> Commit: Jan Beich <[email protected]> >>>>>> 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. > > Hmm. > > My build in a armv7 context with arm_bf16.h listed was of: > > ---Begin OPTIONS List--- > ===> The following configuration options are available for llvm19-19.1.0.r3: > BE_AMDGPU=off: AMD GPU backend (required by mesa) > BE_WASM=off: WebAssembly backend (required by firefox via wasi) > CLANG=on: Build clang > DOCS=on: Build and/or install documentation > EXTRAS=on: Extra clang tools > LIT=on: Install lit and FileCheck test tools > LLD=on: Install lld, the LLVM linker > LLDB=on: Install lldb, the LLVM debugger > PYCLANG=on: Install python bindings to libclang > STATIC_LIBS=on: Install static libraries (does not effect sanitizers) > ====> Options available for the single BACKENDS: you have to select exactly one of them > BE_FREEBSD=off: Backends for FreeBSD architectures > BE_NATIVE=on: Backend(s) for this architecture (ARM) > BE_STANDARD=off: All non-experimental backends > ===> Use 'make config' to modify these settings > ---End OPTIONS List--- > > Note the ARM (no AArch64). > > It built just fine. When I looked at how arm_bf16.h is provided, > it looked to be built via llvm tools and is not direct source > code that as been committed. It looked to me like arm_bf16.h for > an ARM build got ARM (32-bit) content. (But I'm not expert.) > > The firefox build attempt found the file and got no complaints > about using the file. Sure looked to me like it just worked > when it is also listed in _BE_INCS_ARM . > I'd not done a file comparison before, but what I find is . . . FYI, even with llvm18 installed on a FreeBSD boot of an OrangePi+ 2ed (cortex-A7 form of armv7), installed via the a FreeBSD package builder distribution (so BE_STANDARD in use): # more /usr/local/llvm18/lib/clang/18/include/arm_bf16.h /*===---- arm_bf16.h - ARM BF16 intrinsics -----------------------------------=== * * * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. * See https://llvm.org/LICENSE.txt for license information. * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception * *===-----------------------------------------------------------------------=== */ #ifndef __ARM_BF16_H #define __ARM_BF16_H typedef __bf16 bfloat16_t; #define __ai static __inline__ __attribute__((__always_inline__, __nodebug__)) #undef __ai #endif The file just does not have much content when built for (from pkg info llvm18): Options : BE_AMDGPU : on BE_FREEBSD : off BE_NATIVE : off BE_STANDARD : on BE_WASM : on CLANG : on DOCS : on EXTRAS : on LIT : on LLD : on LLDB : on MLIR : on POLLY : on PYCLANG : on STATIC_LIBS : on . . . cpe : cpe:2.3:a:llvm:llvm:18.1.4:::::freebsd15:armv7 I no longer have my tailored llvm1[78] builds, so looking at my tailored llvm19 built via: (BE_NATIVE for armv7 context): Options : BE_AMDGPU : off BE_FREEBSD : off BE_NATIVE : on BE_STANDARD : off BE_WASM : off CLANG : on DOCS : on EXTRAS : on LIT : on LLD : on LLDB : on PYCLANG : on STATIC_LIBS : on . . . cpe : cpe:2.3:a:llvm:llvm:19.1.0.r3:::::freebsd15:armv7 # more /usr/local/llvm19/lib/clang/19/include/arm_bf16.h /*===---- arm_bf16.h - ARM BF16 intrinsics -----------------------------------=== * * * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. * See https://llvm.org/LICENSE.txt for license information. * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception * *===-----------------------------------------------------------------------=== */ #ifndef __ARM_BF16_H #define __ARM_BF16_H typedef __bf16 bfloat16_t; #define __ai static __inline__ __attribute__((__always_inline__, __nodebug__)) #undef __ai #endif It is the same content either way. Same for aarch64 BE_NATIVE: Options : BE_AMDGPU : off BE_FREEBSD : off BE_NATIVE : on BE_STANDARD : off BE_WASM : off CLANG : on COMPILER_RT : on DOCS : on EXTRAS : on FLANG : off LIT : on LLD : on LLDB : on MLIR : off OPENMP : on POLLY : off PYCLANG : on STATIC_LIBS : on . . . cpe : cpe:2.3:a:llvm:llvm:19.1.0.r3:::::freebsd15:aarch64 Overall: Looks AArch32 compliant to me, not specific to AARch64. === Mark Millard marklmi at yahoo.com