On Sep 3, 2024, at 12:09, Mark Millard <mark...@yahoo.com> wrote:
> On Sep 3, 2024, at 11:12, Brooks Davis <bro...@freebsd.org> wrote:
>
>> On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote:
>>> On Aug 30, 2024, at 21:26, Mark Millard <mark...@yahoo.com> wrote:
>>>
>>>> On Aug 30, 2024, at 20:33, Mark Millard <mark...@yahoo.com> wrote:
>>>>
>>>>> [Subject was retitled.]
>>>>>
>>>>> On Aug 30, 2024, at 16:24, Mark Millard <mark...@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 <jbe...@freebsd.org>
>>>>>> Commit: Jan Beich <jbe...@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.
>
> 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
