From nobody Sat Aug 31 05:05:06 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 4WwjdJ2ZWgz5TbtW for ; Sat, 31 Aug 2024 05:05:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4WwjdG53dcz4Vs3 for ; Sat, 31 Aug 2024 05:05:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BJFnB8hM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725080720; bh=wnJMmm/OgpfPWGN9AkGP62LEoJXQb11f8T7p8WDh/Yo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BJFnB8hMzyJ36CMhVd7S7DyeLMWIuLC1NqQXS+X7YrBoHd3LOa+na19E9SqTDnvIcdrqtASX3D+juAtmT9xdHXyZ76FSPvQ2PQamqMbrKzaaf7Dgjf2YRJxf+u1hysyqkg/3ssCggdFJQ+H41zFL9Qj92O4P2bq5+qu6MhHSYwtEqG/UQP9loIu7WLBl6BCXuLUj4NIXcITiTBTp/ijxxuumzyDTFdkvUe+0mx8l2UEiE9wRP9WJJueFGW0TOUs9XPw+kqpiPMAPdo/5q5yo2+WyCCbT1BQhcYPt03T4GrXxlrYkXUr3Vq4T+kOZo4CT3XiHrwhfwDdNEzlMT+n3jg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725080720; bh=APeuQRfBHqqiBCJQK54t1DTYh76z/wb2K8EheiJ1eed=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IWl+Y+hvcq4Hm5Zr+plAq2IHmvE2YWefVwHzghHB2qhrTSnLj2pwsekHyQWMb+uIlUkS2h7gWNs5E4iJE+jzKTRTfK7CcmT07O/FAJmAPRsbJYmtLNBsmgRGlHo4fmfkiuGqtJxgBf2W55JTGqhPu30CnyjXm55p0OXScPdDhrIwLkV7aaFW/xQTffiQFCN0wMbaxLO0tMqZ3QzJROF6LPJw2WXlO1tmw2YY24LdPXzJ8hkYTl7Zl+bwzWydI3pOMQEZmvI4s/BlyAoUuZd1DephRY5YOjcDt44Os+NN6MNXz63oUZUMCLnHUDCFPESNPl/3KjHN0XrMuRICU5Po4w== X-YMail-OSG: jDij.d4VM1niSlc..nb_2br_z1HC9OuSUz5BZxyr0Yssd.O.iRGcTVaj3dcWnt_ Oh3VrU3So1BP1T3QFBLdG3qNuKGs0Hf6uQaK0EXPckRMrSLEWKOvQhuwR2tGnTxrD_0H4dnfN6uo 6Qgz8JOiSIoASd_6R0RRBwj0qsEWFfy3jZj70Lj0qp0.fItL8opMc4m7aeyZKVA9oJykyTw0UerO U513BvwoMYAqlT6OFQcz2KFrVYG38Pp9JFPBD_Z6E8Ei0rd9EMKw_Adf6ImS.hJYaDItbitMx3WK sKYFadKdtwZYOaMkwcgH2vsrAo.2xlOInHp8uTh42iONxOQDDcDejmztKCbMWXeNG9oxexm0Y2L9 n4dEviSuG7oRRYn91_f0ysIzEpJjxVoyzy9Pg0uGhV6_p5w42vOVoEsN2sMchmnB0FV_aYrXNC8x 0btnQgNjHOSJGUA8JeHqWtWMN2j7Ex3sWURNvblrCN4fnZb261S.bF7d.ypA1Nvv7ercfOWrNJ.r pgX09d1I3aEZnbulndi62nIHGhIISuzEhAS_soaDFwgxuu2Jag3J1vJp2YMt8kN9GTuqi5ITJQ0m p4K2c9o1IqHK7Wb_1ZFHM5oGsmg81ax6CG4Ua.qcGyx4l7tEeiRTpz7Z2RJgKGnDOcOfz7K3ZCRd TgCGXbP4G8KDgOtkPfTJ.DD6B853UIPliUswpVyh5xv42CGZAGaCkAIRu.hkL8RiUMNp2UqodMZa 0bRy4yGyyt9N4OwWuGMLVtbPL_CeBN8twFapckHP_LNZqDtvZvJdUHyuqoLx4SmCAQMj_0qq0BiX rS4U7BC7xR2cJGJMczVWTzsGb6PnbQ5dyPX5gj4y5l09uJ32xl5arjt7oN2KyIvt6PXDZaiixaGp u2HbnPDln2MdPh917uNrEVZvQerosYlLdwR7if5M5eauuMm8d8fZJlLB5rWHL0hyRydm3H8ioh5m 9el7JZ59rusU_hqJvdSOcxX01qVBC6OYJemWNlIu.QwH3bcIKDiPKOpk7r2aQYieZlPqNY2VHKvi ATSVVBBs_9amLo7mKRfR8CIaaoWT7v1t0JpZku4ThgQwOt1MPSC_EdbVi4cUdppsL2uoep1k.0I5 43rGyvUOOt7DXhXKPl46Mirn6LHM7UW0yAMzhD2YF.6qd5QIOZzflGD3mueKXZLxIVdxFBnUU4Kd XTsPR5Of2DC4U6T8EBGczNQeVzzydY8.XMfyNvzQwVEOFheSvCbSNM2nz_tUee0se_CTM3t8zd_y iqs4ikcrw_9VAHrZGnhzHv7vyngQOtW_0levAWKwXnZizbPAwYRQjxAIbhaF4JMEVUybh2O3Ojl3 L3Akb9oxn2lp_3LiMIbKtOftbsh53P9mOTRhJe_F2Vrd8zoQjMxlcQLX9LgxTzzbkLsV2aFGd0Tt LyeXwxmfOwHHwAqQTSvGw14GN8E0EzqjMm_dXFvvF35QxSqynU9kvKkpmmb0Isk6rg00LXJ6Bn78 2aH5APN4QXUNAkeKi62t13cFVNMxNW0aHtitUz0E2W4CtbS7f7xbcerXK32Gz8BHhHuKHL9OpETZ WGgFH.uNxtgRSjPsYrAQxzPS2xTuS0LQ1FW5UddEOvu4S6vkquEWvle429KumddR95ehmliZgeAg TcJEeINP9mS.mheZHH.EyW_tQvg6ZNWgRSWbiYVTHII4jX2Ymyqpf1NQdYmjjMqOHe_XZ1XC4fvX 0ub_DPNpS2DgkrcCJaHA6IGcZOXQlRxuGR93W_I9pGW9P2Z.aQ.Q5zyYDLfxDvuqBiGqkobKcPX. CS2xstSvKS6SfzpU58NjNv_hYNX2RPkaHsDQAOfGcyU8Nm21IhNXKZHmaqkUmK4f4uVZwBNtZgBY OV3zUQ1OfzQVTjkgNiQB84sz.ujpV0VuhsrU85628Uj8lKJSIld4jwnCoC2wCb3Uv9iVGp_JbXLO EaYWWE4A6y9pSXyS5Y_RS15zpcowUbR_hSd1VQM_5IpaB9q4rQhr.u5wXL05zCbU00olwrYGbd_a 7x7ieoeeEOT5J2CC2a0o.pHigY3iU4.btLKolC5xZFueO5yZHPmx4ywCrNxZlVm7SZq6BvsQ.vPd hWQvscV.RDKuNTK.s5UM9Cwj.XQjSAoHxEIsZw.7wPR6zN6vecv95ziV3T7mTH6aTvTcHW071TNf pxyn7A202ohpmk557l9SrQgvPeg5fVMg2L2HbDjDcgBBRP0O6wTrBeX9wtTCMhJGUXGmJ7mbL4Xk ChZJr0HMZJx34BCchWW.CnxX9ytcStojSZjLb1C9L_nehN9B3k_tfV1M0jTisadvLChso4dTCg.I TTUFlvB78SIIELHpDyI4VRjVldEhSUQ7YqPJynb7Y5Q6BlJo- X-Sonic-MF: X-Sonic-ID: babf24ac-4270-4c36-bf8c-946d40ea0cd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 05:05:20 +0000 Received: by hermes--production-gq1-5d95dc458-b574z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a48c938e75bb8d2de92244db149046be; Sat, 31 Aug 2024 05:05:17 +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: Date: Fri, 30 Aug 2024 22:05:06 -0700 Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; 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.64.82: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.64.82:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WwjdG53dcz4Vs3 On Aug 30, 2024, at 21:26, Mark Millard wrote: > 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.) 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). >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com