From nobody Tue Sep 03 20:10:21 2024 X-Original-To: freebsd-arm@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 4WyxZT3cqdz52S50 for ; Tue, 03 Sep 2024 20:10:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4WyxZS1pSRz4hw2 for ; Tue, 3 Sep 2024 20:10:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=obGoVzeS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725394238; bh=L9r8cAcxzW8J/JBsLEwMZp+UCTXDgQEm+QXe8oZk1BM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=obGoVzeSv7TX4N9ReEhhHNL7Up3kpSuPiGWZAXIumi5oi2WZmBoS4hdmKVvd2ugRPFRZQk0vjTY4rXwav/m5Ec5tm/lKfdLvHu59ytilhJpyBKaKTj84zuqF+Z8xl41pqbvfbhePDEtWHN77dhUgYlcSHXDdikDd9rsZFkzqZK4RV9ac+4QgI6JpTqS9xKzqf0CpnmvMHXrDKEaDLf4Jg3Az8iMbvXQmRZZSNefqTCyRj3glium1hcqLQ57+0plUgX3pGTJNr00d5+8e2MeNHru+I0DIyfR5NpdnJ67ukkVsSvKNM8m73vCdZvBvBK1vVK+UuF49mz+yClx+PydVVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725394238; bh=aqvlXKmMPhbJyB4tt+JaQW9QKml7HUjQ5tMdxvMGcPl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VLq7Pr1NRzC5XCyFv1xVRm+mx7jdJSaaIaYZ0yKIy/EsNNaSTSubFndaFPXNMFzu+ZTDlqk4GNuUyUAxbN78a1fLeeu1WpPfPwbJE6iGHML7kOvse2K++p6xXf7O55Xd+Cu/lOwwJ1a0FUWp2LEdcgwPspxRZwZJeUIOi17Ultb9Hi5TPnY7V56ladtDFcdTqAU823NsKjKgmFNDpHHZhqFNQ5Ps+s3ua23GlBBGKkNG3CADNTRbhXnFil1gYL2WVzy07vPjrfTEgXFfhkWn7M/nvYHOawqqFklpWmXJzdyjS0FREikE8wk7BcpHwl/0ryPvuYiOv9iFJXivRWoksg== X-YMail-OSG: iSNDd5AVM1kpHhcF.Gvl5.pMrnfefl2kFe0z0RVnMhpw_0JiXK3Xi_uFZvxwHA7 pyV7a.DkzbRTyPeqRWa4VsBtggh0giIMQE4lRcPsIW43lkqCxab3Y1RvIQAT41_5VzBPvHxt_P0Z puXzLjmQRkXvVCIFLbqFYXGtRKLTuNgB0PcDoLxP8IbhNJtZyZoJ7SGAWX6aJnbUo81zKpeL8R0S QAVXnvXBtFmIatD.iHFVtRAtbbHx0kDCdyKBNb5fihhylD83qh45O0G26SUt4cGGYM_Qok6IlX_1 4IdKLW4oBbI2jvC9QWSN7GJGzWpJqzyTQPWDXh_85DeODA_V.jtmQ9KvQmL6RKksEcPnnPOKDWnh CrCdvC..XNGwoQMbzPm7tT5_VKD1UL7cIQ6QEzKz_H0Py7HE_EdIwWxevvknoF5WVuDk2i.kHxLA iFNrN2e_EMDdrhSEVBqcHr6gk8I8RzhgRVupNdzeJ_E3NyktnOJ91FwxQj5h93wzx3w8SEwCc4au ba7fYpdNuNI4GtPTnETNA7yD0sNG2pFdFjO1I.Rcce8K6Y1BQTVqxYdNbAS98i.5_roMCfM.NwQ6 Juk9VkI5QbgLN_nOX3OQpAHazC23BM3DB6p5NoyhlO7HSP0n09gOKvL9xHb0ybRzCd9yW.gtlOjQ ATyUhLKQuOIjIGxucmWIN79xS9MnMM9LddIbl8poTyfmy3WHLrvID8CzFa9.m48Lxote25i1wMQp WhB6Hh_ydMG_2eZZgqZAYs9gwvsu3ciMtH0hGPfG7_7Y9uAizit5Ijk4QVY7onNvWGrr9WXDlqqI eazIPDgwOh5bJ519IYro1jypo6.4Uw.DmwQBh4B5XvYQ_nvIuvQjn4_IcqaEGJGy7_3b.s3wmtbg F1YyDz4tuhc4ae8qD6v9.ZzMgM7S5aKTCDKnmpw1XRDULEgpEIjxLno3QKVijBARr4hyU13rksQL UUzJIH1exI84w3T4.zG307G3Fl8Nk0RQ9fnxrPXIeBZF7Yx.g7wCkxfhhNLowU9PNNgVk74.G5od QdqBLMO2WHakSFl9Zpoz.rD8hEEX8ANdalfgqp4.G7ZAHRyQvdVKYOUdO_zW7.X445PDi8RmrsI. dItZKQhihcwsW2ZbAnGhC4lS_uos1frGovzF82gkODXqBRkz8b3h_BpxPVolNFz0ds67iIV5jmNr qfZWF2DbcLfcLTs6cTrWwEfnTHqO5u6k8N202iLW_GezHAQYaZx8AtuZIiXtK4xZS9WQAj1iRmRE 8KrbozkSv2IRCWkqum4W2rbVdFv3BbvHHdqXgNkwoSF0sVCq7nLqT11IG6okFGXS49Wox5JvsNN9 aAjDHlITmS2OeJwG5h1NJLVuZDwOFgmaPV0w0ooMhz3XM7dqEL1Pe1t8OSmcsN_EJjVnElkRS8Ta 9w4cYrDxeZXx_kYxgRGKt7120AJYjqGmUlasATp9nInoYGZsqXvztkidzzQnP7EZG1SRYsvsMt_f 215Pyxlx62Uq9Ecu8b9C6TOr8gszBmzCTgtS0r42B3gOgcp8bsPEgtphaQHhbSZEt6SnFcKFKWUZ hlDx3CBcXF5CQbUy5bxV6XnkeU4IOyZbWB4BK5GSdh7SPzlA4bhp4XJzxVlTnjBynvxrqPQMyXW3 AuulmMwjklKolP2Ar3MIRHDnpMI0wFIhheJv2WSJeWOcMuoLaoSM3Tg6Fe3xOGif3yzLTP4fEVLz KDBNUmkqTqydgK_lzvxQJ42OUE5fb7uSiD6yfJGj3_A5XiGtWXmMF2crAsQKz.SAolzuN7VJSz25 1iWXB_0GIx.bvj_1P8fwA1zOQqb6rPiwwFbASEQdGUDK118eZDlCkuloHtk6TAWECT1Hremgm0ZK lcBGykfW14WIoxvMyexiqBMw5VkLedrLOcvYv._eln_gdJaqr79S14e9bu5PD93xPK2RIF0dCSzx M86GiB.JhMZkepWESWGbWHVjyuG2.YIR5dTgChbhoF4V.OqwGZjrNGX8wcQP0eudJeqReeIsOCPY c3Gll9Asaxt55napW5iGw.eorThp6FBobXMh_53T7JX3oEga9Dv1EQKMhXUHV4RsoA7CjjlcEv9h 2ra3YJk4MbC41GPBshtB6eovVlfgBm4yxcxWkzum52KywrpSfK6vmrex6oPAV3iYTOAVg6_HjqjU zyPlRi_jckcYJhT_QL1MKTlh6c.hOzc8IyCzfrgA7r.GsP3DNy1sRmoEuSypH3LgWZWrGYsNiQWW pSl7R4I88l5eiqn1yTiE42XU8dbL1bs54jquIAyIqJhl1UDfBzkcbEnti10d6Cwo32eWywJ7zCgz mnSBOcWu.7QPG3U3gQtM7i_NeMnF.6XOWRJCJAw-- X-Sonic-MF: X-Sonic-ID: d2eaed0e-0689-4d2d-b724-89cd5f21ede5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Sep 2024 20:10:38 +0000 Received: by hermes--production-gq1-5d95dc458-vkwd9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 026cbe092810996ae4c92e19aacfeffe; Tue, 03 Sep 2024 20:10:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@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 In-Reply-To: <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> Date: Tue, 3 Sep 2024 13:10:21 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <064B1430-132B-4E60-985A-2115DEF6BB77@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> To: Brooks Davis X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WyxZS1pSRz4hw2 On Sep 3, 2024, at 12:09, Mark Millard wrote: > On Sep 3, 2024, at 11:12, Brooks Davis wrote: >=20 >> On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: >>> On Aug 30, 2024, at 21:26, Mark Millard wrote: >>>=20 >>>> On Aug 30, 2024, at 20:33, Mark Millard wrote: >>>>=20 >>>>> [Subject was retitled.] >>>>>=20 >>>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: >>>>>=20 >>>>>> What my test-of-building got was: No 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 >>>>>> | ^~~~~~~~~~~~ >>>>>> . . . >>>>>>=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 >>>>>> Commit: Jan Beich >>>>>> 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 >>>>> /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 \n"; >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << = "#include \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 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 /*=3D=3D=3D---- arm_bf16.h - ARM BF16 intrinsics = -----------------------------------=3D=3D=3D * * * 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 * = *=3D=3D=3D----------------------------------------------------------------= -------=3D=3D=3D */ #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 /*=3D=3D=3D---- arm_bf16.h - ARM BF16 intrinsics = -----------------------------------=3D=3D=3D * * * 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 * = *=3D=3D=3D----------------------------------------------------------------= -------=3D=3D=3D */ #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. =3D=3D=3D Mark Millard marklmi at yahoo.com