Date: Tue, 3 Sep 2024 12:09:55 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brooks Davis <brooks@freebsd.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> 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] Message-ID: <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> In-Reply-To: <ZtdRqxBPukxcOkaz@spindle.one-eyed-alien.net> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <E029410D-1964-4C55-8B2D-0427C43B4ABA@yahoo.com> <D74514BA-9071-4F29-96F5-42AD6EC2B6E4@yahoo.com> <DF65D496-D1E7-44B6-A04F-EADA1DE29817@yahoo.com> <ZtdRqxBPukxcOkaz@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 2024, at 11:12, Brooks Davis <brooks@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 <marklmi@yahoo.com> wrote:
>>=20
>>> On Aug 30, 2024, at 20:33, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>>> [Subject was retitled.]
>>>>=20
>>>> On Aug 30, 2024, at 16:24, Mark Millard <marklmi@yahoo.com> wrote:
>>>>=20
>>>>> 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):
>>>>>=20
>>>>> 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>
>>>>> | ^~~~~~~~~~~~
>>>>> . . .
>>>>>=20
>>>>> 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/rusti=
x/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/rusti=
x/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
>>>>> |
>>>>> . . .
>>>>> =3D 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)
>>>>>=20
>>>>> . . .
>>>>>=20
>>>>> 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/rusti=
x/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/rusti=
x/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
>>>>> |
>>>>> . . .
>>>>> =3D 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)
>>>>>=20
>>>>> . . .
>>>>> =3D 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)
>>>>>=20
>>>>> For more information about this error, try `rustc --explain =
E0599`.
>>>>> error: could not compile `rustix` (lib) due to 2 previous errors
>>>>>=20
>>>>>=20
>>>>> For reference:
>>>>>=20
>>>>> # 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
>>>>>=20
>>>>> # ~/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)
>>>>>=20
>>>>> But firefox was updated to use: nss>=3D3.103:security/nss to match =
what was
>>>>> available.
>>>>=20
>>>>=20
>>>> Using devel/llvm18 instead got the same.
>>>>=20
>>>> 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:
>>>>=20
>>>> # 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
>>>>=20
>>>> Looking quickly at more llvm* shows:
>>>>=20
>>>> # 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=3D =
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=3D =
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=3D =
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=3D =
arm_bf16.h arm_sme_draft_spec_subject_to_change.h
>>>> /usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64=3D =
arm_bf16.h
>>>> /usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64=3D =
arm_bf16.h
>>>>=20
>>>> llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more).
>>>> llvm1[789] do not.
>>>>=20
>>>> I wonder if:
>>>>=20
>>>> =
https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=3D778e212f2=
34a825c5e19612df4be2e8f838cb024
>>>>=20
>>>> doing:
>>>>=20
>>>> -_BE_INCS_ARM=3D arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h =
arm_neon.h arm_sve.h
>>>> +_BE_INCS_ARM=3D arm_cde.h arm_fp16.h arm_mve.h arm_neon.h =
arm_sve.h
>>>>=20
>>>> was correct. I'll note that in an armv7 context:
>>>>=20
>>>> # 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
>>>>=20
>>>> suggesting that gcc14 considers the file as not aarch64 specific =
but
>>>> as armv7 compatibile.
>>>=20
>>> I got that wrong! arm vs. aarch64 have different source files with =
the
>>> same name (under different paths):
>>>=20
>>> 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_
>>>=20
>>> (More content is different.)
>>=20
>> As for llvm*:
>>=20
>> clang/lib/Basic/Targets/ARM.cpp has:
>>=20
>> if (HasBFloat16) {
>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>> }
>>=20
>> clang/lib/Basic/Targets/AArch64.cpp has:
>>=20
>> if (HasBFloat16) {
>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>> }
>>=20
>> which suggests bf16 support has 32-bit support (even if it is armv8
>> 32-bit). Looking for AArch32 state in:
>>=20
>> DDI0487K_a_a-profile_architecture_reference_manual.pdf
>>=20
>> it says (via the AArch32 column of a table):
>>=20
>> BF16 Supported if FEAT_AA32BF16 is implemented.
>>=20
>> Looks to me like the removal of arm_bf16.h for llvm target ARM
>> was incorrect.
>=20
> 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---
=3D=3D=3D> The following configuration options are available for =
llvm19-19.1.0.r3:
BE_AMDGPU=3Doff: AMD GPU backend (required by mesa)
BE_WASM=3Doff: WebAssembly backend (required by firefox via wasi)
CLANG=3Don: Build clang
DOCS=3Don: Build and/or install documentation
EXTRAS=3Don: Extra clang tools
LIT=3Don: Install lit and FileCheck test tools
LLD=3Don: Install lld, the LLVM linker
LLDB=3Don: Install lldb, the LLVM debugger
PYCLANG=3Don: Install python bindings to libclang
STATIC_LIBS=3Don: Install static libraries (does not effect =
sanitizers)
=3D=3D=3D=3D> Options available for the single BACKENDS: you have to =
select exactly one of them
BE_FREEBSD=3Doff: Backends for FreeBSD architectures
BE_NATIVE=3Don: Backend(s) for this architecture (ARM)
BE_STANDARD=3Doff: All non-experimental backends
=3D=3D=3D> 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 .
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5BEBBFCB-A877-4124-B07F-D4C6D25B7026>