From nobody Tue Sep 3 21:36:19 2024
X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WyzTZ1qbhz5MSlx
for <freebsd-ports@mlmmj.nyi.freebsd.org>; Tue, 03 Sep 2024 21:36:34 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4WyzTY3jR7z41sS
for <freebsd-ports@freebsd.org>; Tue, 3 Sep 2024 21:36:33 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725399391; bh=TX2clt+V65ghKShznG3RgnbZolGAe+DECuPeji/eT00=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kRy2DtGesf/HoB5gicNtsFonKkGsmH/FriCVlUJTTwY83Z0lijnPu78GWANE2oISDJd2ul3O3/w6ocomXwLrPd5iOCT8KsTxUzL9Z0Q4le+COJyod/qSlNtVnGBLLL01yP5EJx4h3e88JVxwXEVyn8xtgFmMkQl0r46aZGzrIWl4tpgctvGYU3YhitwsxP+AXZDxK3Hc0twpQcaeUBrBTrfgItMNT30MBUfJlPifjTPwwh56Q92fPQ2YEmN9znHJF5T5GQoUydkB5QRc0PlFfGsVL/CWLAEFDrVCNHu1WJqiVgWpNJb28m6ho0EpBMP/gGS0PMGv/aT2rtlxTPdiFw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725399391; bh=NrBm2Esn9zhT2z4v9GJWPBcfXlmsJsemC6K/5am/EJw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YB/wnwtb2VrGvIvNhyohb7nWL2+1x7fB0fJxmsqNrFrBlAwXtzpCpFzwq4rzs/5fHb7KqB8RlesKPzafkC8z0k4UeEPSXhJyjPDlef2acVBoFXhZ595qFsAE7awqOgqqo5gLBjAoebuvbRBs/Aud4RDHpUnWDBfdwPh+qMlgJGLycCTSsz0Rz71fmsC/kNzDV/Rx7HSb/7i81PvnxHYPEY8OqxWw0/QNCsIxnv2XahJZ6xSSZTmBO6TznFxOLU5sdAnRCgmYhdGJSUTbolYR8svdKenKZVaBomAPBVYvPDKSi4r7DzwZF77uydiS8a9M9HBepPqtp8Nt0dovfnLMIg==
X-YMail-OSG: PSdp6.0VM1lBI4Bob30jDRnZsztzaU3u17H2DVTjtrW_Os4SFrZ_xqRQD8R05ln
tFEPIkZgQCDTxOzIH__wtMAB4PmOSOEXW9fNp9kyzwjiRS_6ocEwZGxUxDjqrTjDxMLQd5K_a0na
Eu19TCJnktYU_CsYPuCMqiiqKiGqRyb1KKGEOkYTK5N8rgRNJJ9jGjNR4kbOYLysLrYNBgiZ4kiy
Zev55JkCoY.nbZ7BuHxJzOl2S7Hx1rXa3XwZkOAY1eVqsqlr9pS1pNPpO.YySuOdUf51MDy1X.cF
UJIR2NnUu7i2xFnuHnrpYpsWKmjysfG3SV4Y8aGn.WFX5p.7FZn4eSHXtz1teviL6e3RQWkhtbpY
g3DfJnEdw3Ws63OyJ7pBbqNqZCJsGasJvUMpT6cnEoV8W7NonLWOiFWTk09Xl1oGQ3dN8BIIHorf
qZmmHA6iK6l6W2UhNGZ9_C8FDe95tCXQOHvbqbKUigFbQ_pRncqYAcyq5P2QThVm0cRyh0x5rULj
o5wZY7qolgrBuU966Yo0wjUwLYpjoumMIyLdU9HzYTUl3zZTcSwTkbN180x0L2dfs_YSpuRkWCoy
dVQa70Lzzh9Yb1yRT2UltFYTWde5ZrgkulMHEsrOVGv86XmuBgHSB4kk.g96nQCjexGYTpQagCKf
6x142wuw2DK4uRM1RpcNZGdVIur.oPFSCqD7OTln.tNEDAQolGt_2W5lOi.RcBQGPJYJDnstubsV
ok8OzRdDT8gFX96HlgrKtP6uZl8boS8bxulRjGoz6wv.aqLqroZz1ZkbnU6eYF1EOA4sANK8Gl75
d_BSOwwpOL1RMjhSohvOWlJnCSVpkAQ7u3f_62wFq8mSKFNBVC521IfbJYFZvAT7_d3u6T6I2rJ7
aibj8wxoK6eqDxss1.ZGa3pwVcKiENoZ5lqEIcyBBai87szWfXF6bGTipTM72.7XBitmOc9NxR2x
3ciTbSEDGItn2Y3vKCKFJe7IWA1g.e1rBKxL.YeJg0uGvb1fBJa9nL3xtVzYQ0CPzW3XZ7gt0RS3
hzj3gcHOm6DKbjPupBuUbXyvuNv0698evtp5pcmh14Wza2htqZcYxuqHKPFNLNhGvYNCf2tvTpzX
CsRQptAzkHNkx37buRvJDTxXPKjRAkRIvkKpStnOmdOjMJ2Yed64u63k8ryPjEsSHwunmbtaKOdx
ysx4_aMWqRXLKdkPuA6bbCS5OrjYY70VVJMNKMK0Ucpnh_fAiyXeCxJ5GmxHFur5rwgZkb3niruX
3LeiF.U.EJehdKJaX2LfpkCSCdADZBaHbe3eiX05oJPlRNYmMUMpbx_y7iWSEEPP8uM5W_Kg1SpH
081KDr1o8mLBveU14FbnnYqGkN2mT1UfkqfeLItAOt.vIZ6o_M4BE4hYSDjm94wm1N7qkC8NGAFu
fGxf3PVwNCHXHgGCieTnsjPZKQPAOrESfnizegeNc3i0Mr780l33eEHEdpRb39LZ68s.q78rDRHt
fHrO7xuB37Wn8mO.jVSRcLsX3jzuzXXsFdj0ffjZ3HhC2NB_VF5CGUeM87wxWISzi5KMQlUZc6dA
fBiptBlcFPK0ZdUp2hYxsylWQcI0Tn3Fcpy1Of2AI4wdZYXtmjHTjgrb7MVcFdwIN2GMykSsvAxA
QtiuE_4kWxA37uR4FaZ537uMbAeHNYAiMO6Egh6xQ9.2AOqK3UGxkKrFg3sahNywgDlB9.JC2wEU
_vSveeYB3bCdnGqtT_9uOdVML3SUH6rDs4u2pPXTdA78w1mLRIXSnhM28RVYhmN4tlYh.E_Btr68
cO18nb7Zf8J2jqCHDzZ11C_CHH1RbMo6RLQgxTiyv7q8xNF2dcD.TVRPDcHTFXVWMS_tglykWeIW
9yLMOM1A6vO442aSBE48LtKHr9LMu0tHKKlmhjvYfVf58U2.U7fLjESkLlN8gJIJ_PjLO816C8A_
rYU78UIgXqxVG9Xf6O8Xrez48c2lFHiyTJTnqGLlfgnOoEGSMNTQnwj9XElczHQyquhYtt4oTooO
UGkbJzI2MULrj3GPmb4II8S51BnFSbDcXt1OSbkx_dzQ3.vPpeEaPpcqhDcxNtffrfJG8JHKsR2y
JuV3AvTgAwA3Lt8Zy70ofdzeFIVtmhGvddQ30b0Q1VYUP6D_IuPeUyjeHQwr7WjwUIJmVJc0svd8
2xWclGUNvt7uIWT1zwTYGAM75XwQsvLOGeS3QKWLUKDWjIART4o2BYNJbaDpKE.DYXRhmWFhtHm5
PkS_4.5fl6.0I1JK7A1_tT.wmOIjPm77LVitTFG2gFJ_CuEC22Z9BLyXzwHHN
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 7e81847b-85b7-49ff-a88b-e9e5eb719178
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Sep 2024 21:36:31 +0000
Received: by hermes--production-gq1-5d95dc458-s958r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d628bc46b77ce74b5d6344e12a78fa7c;
Tue, 03 Sep 2024 21:36:30 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-ports
List-Help: <mailto:ports+help@freebsd.org>
List-Post: <mailto:ports@freebsd.org>
List-Subscribe: <mailto:ports+subscribe@freebsd.org>
List-Unsubscribe: <mailto:ports+unsubscribe@freebsd.org>
X-BeenThere: freebsd-ports@freebsd.org
Sender: owner-freebsd-ports@FreeBSD.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
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]
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <ZtdyWSJ_Vva4tFdn@spindle.one-eyed-alien.net>
Date: Tue, 3 Sep 2024 14:36:19 -0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <02BE22BE-7E86-43D1-86D8-85A527625AD6@yahoo.com>
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>
<5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com>
<ZtdyWSJ_Vva4tFdn@spindle.one-eyed-alien.net>
To: Brooks Davis <brooks@freebsd.org>
X-Mailer: Apple Mail (2.3776.700.51)
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-Rspamd-Queue-Id: 4WyzTY3jR7z41sS
On Sep 3, 2024, at 13:32, Brooks Davis <brooks@freebsd.org> wrote:
> On Tue, Sep 03, 2024 at 12:09:55PM -0700, Mark Millard wrote:
>> On Sep 3, 2024, at 11:12, Brooks Davis <brooks@freebsd.org> wrote:
>>=20
>>> 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.
>>=20
>> Hmm.
>>=20
>> My build in a armv7 context with arm_bf16.h listed was of:
>>=20
>> ---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---
>>=20
>> Note the ARM (no AArch64).
>>=20
>> 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.)
>>=20
>> 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 .
>=20
> It's weird that it's getting installed at all. I'm rather confused. =
Could
> you do a `make check-plist` and send me the output?
The below is about my personal builds in this time frame,
the ones that found and used the arm_b16.h file in a armv7
context . . .
Reminder/notice of context: I was experimenting with trying to
build firefox to see if BE_WASM being enabled was remotely worth
it for now. (It is not: firefox is no where near buildable for
armv7 at this point. BE_WASM just wastes cycles and such.)
firefox uses '#include <arm_bf16.h>' for armv7 builds and gets an
error about it being missing if it is not installed by the llvm
that it is using. So I had experimented with use of reverting the
_BE_INCS_ARM related commit material at issue, resulting in:
-_BE_INCS_ARM=3D arm_cde.h arm_fp16.h arm_mve.h arm_neon.h =
arm_sme.h \
+_BE_INCS_ARM=3D arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h =
arm_neon.h arm_sme.h \
This was in order to see if such would allow firefox to get past
the specific error. It did get past that error point without any
complaints.
Does that addition of arm_bf16.h to _BE_INCS_ARM remove the
confusion?
Attempting to use 'make check-plist' started trying to build and
install a bunch of stuff so I stopped it. I do not plan on
rebuilding the llvm18 prerequisites via make. I've uninstalled
and cleaned out what installed before I stopped it. (Nearly all
my build activity is via poudriere-devel instead of the likes of
use of make or portmaster.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com