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]

On 31.08.2024 8:29, Mark Millard wrote:
> On Aug 30, 2024, at 22:05, Mark Millard <marklmi@yahoo.com> 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.
>>
>>>> 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