From nobody Tue Sep 3 18:12:59 2024 X-Original-To: freebsd-toolchain@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 4Wytyh00FKz5Tj8H; Tue, 03 Sep 2024 18:13:00 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wytyg6Xbbz4M6x; Tue, 3 Sep 2024 18:12:59 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725387179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8eczswHwhPV6HPbp+JgrQZ+pewcpTcLmtTTgbZtEjwk=; b=nNSZ89T9HgwZSUbB01MJgrkClG2IuaY63a9kLrJhhHm3ffAhHcPQH2icEXZrH51HQz3hdi qkwRQAkVK9ECv/Z2Jukc6JWu6jxV7Reke+2veYOGbN4UtmY/SNS1yIzshoBueHblM/vDnj TQAGT2TFibrtrEf18QT9AQNNmEX7j1U5pItNzzvALnnXAOrooijYYYIEgY3KUSV7zR5SHJ 8N0Q313hx4guCM3AFoKgbeGNdN8VTusNnrR9+BMFNW+lsExH2rja4IlbkI5C2uYHND4ZQd o9ED4DLHS59tIrjY4ZObMVcT7CZqziDtEK9f+xQAg9mzR6r7f5JVg926fGGThw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725387179; a=rsa-sha256; cv=none; b=a/8STSA0VSGo64zwOitTJLNOtBir/mA6RnnNBCD5SFA2Zkc7rTVU+6o1/uGaXvIvHHv3Ew nDzFlTHGYi9sHnQDRGo9wFm+EqvkwVMjY32LC+l9HxK4YMtog/iRm6msM3Ofmkk2xhYUXL DWK1FAfVWVRfGERII3qvSu2WjYRjvZgRWH9cWMOjNM5yNhPWYt0v4moJrPNQFXJUbacPTf u4JdD/tdtSFH7zFUCzIALwKq8G1UEaRQYzP3P+DATWdYEg33n9qxUlg50VZ05qliTjoIaI /E/GJdWWKr5fT5eQnf/ldagXivFK8vIB8/T6hPbI/c521BybnX9TPXsJlV+8Bw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725387179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8eczswHwhPV6HPbp+JgrQZ+pewcpTcLmtTTgbZtEjwk=; b=XXux84mlbvyJ8O/NTtvU1FPWUaXATRIwqJ/FKPtWVLdrvHapf3nzyrFVkbwnPMCts4GuZn uUsTL9k3lo2Kzmod0U0Eg5zW9+gqsmzTJeDg2nz7SbhEaOPsrSAGsYjUZMgwe4z3lntzl7 g+lLnpWsGkIvI916w592ffJpsHZFUlXVvM7pePeCuPT5nNfzrsrEg2uWqVdDzsEHCX6/y6 2Z1EaWtuOkNfL8kyDDeX5tCGlFwS35lNJsm3hrmhoD7bvqoGprQEo2y7MdqEQpwQnpmIwk oAXQkYjBPIQDPpmbMez5Zb353tx2EPGgrU+lBagYwmHqXHPk8bFGQx569DgfrA== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Wytyg5M39z1Dhk; Tue, 3 Sep 2024 18:12:59 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 182A33C019B; Tue, 03 Sep 2024 18:12:59 +0000 (UTC) Date: Tue, 3 Sep 2024 18:12:59 +0000 From: Brooks Davis To: Mark Millard Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI 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: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: > On Aug 30, 2024, at 21:26, Mark Millard wrote: > > > On Aug 30, 2024, at 20:33, Mark Millard wrote: > > > >> [Subject was retitled.] > >> > >> On Aug 30, 2024, at 16:24, Mark Millard wrote: > >> > >>> What my test-of-building got was: No 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 > >>> | ^~~~~~~~~~~~ > >>> . . . > >>> > >>> 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 > >>> 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) > >>> > >>> 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 > >> /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= 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. 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. -- Brooks From nobody Tue Sep 3 19:09:55 2024 X-Original-To: freebsd-toolchain@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 4WywDk3ScLz5Tp4R for ; Tue, 03 Sep 2024 19:10:14 +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 4WywDk0WFcz4Vdr for ; Tue, 3 Sep 2024 19:10:13 +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=1725390612; bh=0hqXl851gBsmuzj1KgEBitQqnwallhDpBdRuLp8yNCI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mXNyETj4NbVSG08DwIweYOF7aiqRls5UzKIin6FhPJ7DVfSdSrzDcmKFXfMp/S1lU8iQXAYZ9BFEzvFTCjmeQO5lYNN96okeFgN/gY+ll0pLyki56pxy/P78ySkWJh7qPG52DupDMC7NmKdRVqW6W+0c31eK1xhMnRf+P8pLDp+pAaTquqyma4I+cM+X3MA8gN3bTGJvlrtHEB8fYh344fWZbdJTAP/yEu+htmQdNt6f/h9PqiA0DzKpl/uwO1XMjn85KiiFjlrP8MIrnqLfvtvUXa5i7DKf6KYdS9v1Yy+B5F5sHdHr37GA3Jcc+sTz+IdDCnboAqjvcr9Ns/Lprw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725390612; bh=t4dr7TNboLWiVC9tRHHdiPuPvGA7MZquR2Ze+41FvYu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BScbuD2OcXXUw9iOhTJEPtABRQEpKummlO+VtwBMhLbiD/EWqVWSTvCrpMhJcQ+cDTRyL+lWA0Jsi4WCegHHiqaM64zdGZLWgQBWY/QkzxKb9Thzu1K/VBc5JtWQLFydfPXQCwrlePqPYz/51SljCIuffqCe1sF3pnTmdEgxbLS27epl9VDK1wyUHkAkuFoNs6HPwVeev7bQu+eRt5D48R5h29MayRvZxoyyuAc1ufRpCxVUKU4PUWFDOVxJepTfzLOrZZwdSF6NbRrVBfRrmkAcqQW3Yh7Hop8uyMsrf50BvefyIdt1D/0ZCmoulpXvjbRQiZr+sMBXzoMkUZP+uw== X-YMail-OSG: qC7YMZIVM1mF7HDdJaZcXXd9WznkIztR4Jq5x04Sj1JfT3WmkQBlkq12gAe0WXg aPguI4YrpRh6EQNL6lrTyLO6K8_rA0f9cvCtqbrPMjnep6S8VZAy8AnN4nPlGWUvNt5lO9yGcbtj AgB8WVQA5ahxuT5Y9ECoblz_rSMRlXdEbkajuy63O6HLuTzn7fbfu7etki4O_Ei6XieIuOTcdRT. 643reheCE5aTLiUMp1RhpIcXvXjGROaOZDY2RhPlR03GdRYZiww5wAu1k0T.elmIkZRZ1vJ4CDOn HQe.7UR6Cz8hZIZCcSkeroqKgMLCqNC6PBusb.MvLFuAKxd3Kzvboeto0Epqd3.0ekDzVz7gDZjn Y6kQiREq33jf1g_Lab34Lbb86ow9V989OubnuW.Fcwml39_HE9JkrWkQKavCIT.MFV4YiW4ks.eR kkHU1kNkp82P_MhxkCat_yPgmvwpYklwHIsJ2MMpZ_nxp4yE.b7iOWr__MkMqM.jGH4fUj46EnSv tTlTrlCEVrYyidUU0ZWcwCFjzq5dsVrRvHOp2fuFCQoFLieTyYr7vFOpiRFS1Ku9T4KkgdDMBQKt BtOJHbO91Z_ocCcP5P3t8ieCob46Et9_J3s1N14bMiPLtaVilL7bymeYAVJE4rI8LIn4DGdiT7DV WsmwXP86R6dtscAEjmYU6LOdqUOJDYaKN0HfvJ9Cs2mwhzEimT9FS2EcDVo0p00fkf0RJWeEuDPg 8LIPG5NXQjZznXWniFzaERzZdhtUEo4KR1vUQ5zmssnhrmTAyhfi3GwR.jhcgOEjcmJPayshUy.z fm86Go.gwnDJvuuZ00mTCVRo425nP3I7y.S1tUtOAA0M0n2Shi_oecNp.MzQwDF2qMxdtTZXw_2k Gvr134OuLkp_IqhVlP2Ms0U3g8rVFb1rubiXpYa2etQP4yZUQso3KxOWBxtMV2mQv4xAziZpL3gW fulxtLf.sjEaHTtN6XxssHaeFsYELyHnhOvq__TPYZWktpRR_yH3aUeObDLfQL7ent4dX0AoUAnf JNxxouqW5z8VDqXN.gsG9dfgaQUZrK1xZRvloJk.mFYh6Pezw_LgWBkO5KLAxQwHvQ8bGEplz7ej ZCd4GF5HAD3H_duQSC8v75MKJR34jmlgNGUm8NlR3MCNd9w9AcWzbh5PQLJIhRKFF7sytYssa9Vb W29gplnsS6Zc0F7zusxR1apTKgGdc5wntVHRtJV8w3FFVQ5fc5LoQQu4N9KP_1AvrXv8Zw7IIAF. 1K4NElP81uCJvF2dVYSfSftChGBuB83b4cLWi5akvdvLC7sG52wPnLhIVViXGQUfO9KLBM0NYZQm PNxUNhvz.oGAVBy.KSTgt7OgvdgjAk3Izm5LL35Nw8z6le6MonF2v3NyOR92T4aDucy_JyGuyYR8 49ekDiw7xXMryZ4DXm0O3MdIpZriY_zLZeuF6adXst0_ZZ0PbDHMfpmxUKyX9x810m1mkwZf2OER cy4RjBo3F.D2KPlbZMKUPNwFiMewH2KDA4myggBcWuzvuTaZ9eVj4DsloPDAy3Zly4vUKhjUsB83 r65C8_9g0WSWQZ8EU7DgnWbcqvqCrNU_YVpiPMKivlm7rPDYTXBpqD6O7OLQg25vIQgrMUtzGGMY dCV7BcDWXSPQPlEl0TSxeCfX8UKrxVyvCwO_3ncWNJjN9S8DEAbvoyPmuYb5W61B3o6vvR8ar5f2 j1Yr64ci7QrfpmMd6WyDTIrCP8xfMxqCHdb7mn7QXv83h1ovZy7sdCxlAdx7uXFXuKwMOX5zy8Yt zIWCxUtWZFnlPPxY14xQMQGHIowHcTM7_eRvi158GnGafEfZDpfMWd.X8I6dhFmDdBw2YFRBWZ4N SHLK.LyvwMg9.ixNfbY13vMFxTx9gI9yfdwuzgY_le2hLov.tlMirpgjRWMYeX3oq1WKLXa5Gn_l Pu6NUNIv2ZpxZvv6nWSew0..Pat2HBkfp4wLmD9Fx.9BaP6_HDpC0TSfIcpiLWnrCksYYIZ2k42S QQlobG8fZnZc4LSjpATS2AXKzwLZ39kGm4d8lZdwZSn3pqN.Itu0FwOTZreLRd_MSAjl0QeFlJOj KMMH_LxNPcCRzpscTxfNewWlRphOcpBboV1iWQiCOkROSRmK21.AxPPyi0rseind1MY3NI27bcIJ tZHiP8C6ehJYJU0zEt4d.l7_QQ4S2rz1R..4L9fGiTsqck511Ek2whJRbp16keq.zvSzy_1FGAvy hQUZ81FhiktnfVQjoPpLtMpSbSigSQx8q0F7_9639vnvzxyGjK66UoUEP7pKCqZGyEoT68BIK5pM S8k.Iwe0Uv7Fy95v26Bmigi.7SnsAiQs0ZRxI X-Sonic-MF: X-Sonic-ID: 5a94cd80-a0e6-4fd0-b779-7014e27d003b Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Sep 2024 19:10:12 +0000 Received: by hermes--production-gq1-5d95dc458-s958r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1b474be95e24b56052ab0258afffbdd1; Tue, 03 Sep 2024 19:10:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@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: Tue, 3 Sep 2024 12:09:55 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: Brooks Davis 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: 4WywDk0WFcz4Vdr On Sep 3, 2024, at 11:12, Brooks Davis wrote: > 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. 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 From nobody Tue Sep 3 20:10:21 2024 X-Original-To: freebsd-toolchain@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 4WyxZT3DR2z52S7X 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 4WyxZS1zp1z4hcc 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: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@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-toolchain@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: 4WyxZS1zp1z4hcc 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 From nobody Tue Sep 3 20:32:25 2024 X-Original-To: freebsd-toolchain@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 4Wyy3Z0v6Fz52Yps; Tue, 03 Sep 2024 20:32:26 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wyy3Z0MmLz4qV1; Tue, 3 Sep 2024 20:32:26 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725395546; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eURDqZcPsnWbXA/ImZsf7Uymy9EKzaE6JAKICq/OXpk=; b=bc8XnGh8A/nRaPp8JVzXBfdjcsLJbmRYThH1pfdDtPfLXeuHXg1QoDQzHgMIT60h7CAoab kaOic11X8WjvqOgNmvxbg76T46fItNu3Dxgb83jMR5fg69Z5K6T4fYENWn9KTYYr+zpJBJ HSLOrI7sWjQbOZ6QdhT41LjhyIbLpQPADFXFZNSDmYSyiyqT9qXIFUBIDLR1Z0T7475RjI wWEKDOEwZxB8QVdswz41KFJ+rX6uImofjZLy2yDMVtm6oZzuEJrn1aR9mAmg/krlwD0m1t 9o8pVT+uroUxhR/WwLVlLmjpmKWcG3SY8aRxN5+97U5U8Jbmxn0LwIsh4rXvZw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725395546; a=rsa-sha256; cv=none; b=jfJFjatqgocf3HQnO+VCRAILbKeDkJU3BKujbhafGjfe6cM8SQ4lAmCzZqvM0QetwXEJmi ixa6dPJISyRYmZKNfh78BjewR7GmFS4Grlfq/CPQ4MzPvXrtsrXU/EsBY0i55i5joJitcG NjLNuQHOLO32/E09Q6G0vKU+zZgwXsfDedi+9rV/8UWBnjMI0UDXvoaSGSsxJsa1CRtYEU wDSs1d/3SrfDSHpxlYuli1my7aXH/qI4BuzQR/eKj2gNbHkXvk1AvGynq9nwq4v8LnT+vi /98QCgvBkclqlyIevguhRSkjaAO7JPfef2uVeLaCfOe1zJg0aVSTURUB5LlD5Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725395546; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eURDqZcPsnWbXA/ImZsf7Uymy9EKzaE6JAKICq/OXpk=; b=bErLvAmjV5xl8I/yiTkmqQceDtYc7sIDGq3kxEkb0To1FhBw+eiR/jBhYGJyF/yrQmgjzp CMFa+dvbWbdbhM+LUSdt9+f9tfgYZ5sDsJbS2++E1Hvf+cz03ZwtnyTnkRJoQvmgny38an E2lsJYuwHBWnm1GWAP3CuChQC/4n+OMqImkpxkol+Fqk3MTVCwDAYhFgfbLSdBK7M4v7XD /ZPFCV5ILUkEwiXDQvsYmZPU4QHovuM5PMUTy//PQym8yYkmmfg6RUo+q12Ms0HY1uk7sa vO0wcn2t9vogk3FVcT4cGS0o7ebqqSJrOSb5peDXPhj/w0gqpbxIbsNhCe6z+g== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Wyy3Y6s6xz1H23; Tue, 3 Sep 2024 20:32:25 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 9FC623C019B; Tue, 03 Sep 2024 20:32:25 +0000 (UTC) Date: Tue, 3 Sep 2024 20:32:25 +0000 From: Brooks Davis To: Mark Millard Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI 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: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> On Tue, Sep 03, 2024 at 12:09:55PM -0700, Mark Millard wrote: > On Sep 3, 2024, at 11:12, Brooks Davis wrote: > > > On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: > >> On Aug 30, 2024, at 21:26, Mark Millard wrote: > >> > >>> On Aug 30, 2024, at 20:33, Mark Millard wrote: > >>> > >>>> [Subject was retitled.] > >>>> > >>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: > >>>> > >>>>> What my test-of-building got was: No 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 > >>>>> | ^~~~~~~~~~~~ > >>>>> . . . > >>>>> > >>>>> 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 > >>>>> 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) > >>>>> > >>>>> 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 > >>>> /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= 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. > > > > 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--- > ===> The following configuration options are available for llvm19-19.1.0.r3: > BE_AMDGPU=off: AMD GPU backend (required by mesa) > BE_WASM=off: WebAssembly backend (required by firefox via wasi) > CLANG=on: Build clang > DOCS=on: Build and/or install documentation > EXTRAS=on: Extra clang tools > LIT=on: Install lit and FileCheck test tools > LLD=on: Install lld, the LLVM linker > LLDB=on: Install lldb, the LLVM debugger > PYCLANG=on: Install python bindings to libclang > STATIC_LIBS=on: Install static libraries (does not effect sanitizers) > ====> Options available for the single BACKENDS: you have to select exactly one of them > BE_FREEBSD=off: Backends for FreeBSD architectures > BE_NATIVE=on: Backend(s) for this architecture (ARM) > BE_STANDARD=off: All non-experimental backends > ===> 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 . 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? Thanks, Brooks From nobody Tue Sep 3 21:36:19 2024 X-Original-To: freebsd-toolchain@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 4WyzTZ1qfpz5MTDf for ; 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 4WyzTY3jSdz41mg for ; 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: 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: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@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: Tue, 3 Sep 2024 14:36:19 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <02BE22BE-7E86-43D1-86D8-85A527625AD6@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-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: 4WyzTY3jSdz41mg On Sep 3, 2024, at 13:32, Brooks Davis wrote: > On Tue, Sep 03, 2024 at 12:09:55PM -0700, 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 > 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 ' 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 From nobody Tue Sep 3 21:47:06 2024 X-Original-To: freebsd-toolchain@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 4Wyzjl31jJz5MTj0; Tue, 03 Sep 2024 21:47:07 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wyzjl2PxWz43vZ; Tue, 3 Sep 2024 21:47:07 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725400027; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hyPJ40xTOzUcguhYJn+1V1WFij52cPc0WTRyVArN250=; b=sI8HP2uZsIHwVYcs1PJDZTnpmndu7z5AaeKneicEg+xXFE9uVYEIt/an0s9/OnPn79y8og 0rKWZAie2a3YX5X47PrrG5g+sR824ZkUoTNcT/T0AIzZDwo7pdeg5xPPKj3HMX9wRNtd2P pDPfb8EwvZEhCGpc9NATKLdy5JhzWogPBXoD/0cKBuYcbdhnMedKsVlPmLBPLwx5qbN4hW AvKLqfxRchwkUXhvIY+UKYjrbTf83sMkGl98MtgNWpA4vAQ2oZKgh5QSOU1YXlrGDL6p67 Q5zEUDmh+kH+B3gQ5ZGrZuNJ4mQmnn8UL5GknvMl0DdJ0mQneYiqjBRYZsku/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725400027; a=rsa-sha256; cv=none; b=YiAxDXH4ODPxWi3sIBwIqp1qB25EVj5eLyRMb159sNyE3EyDulqhcpZd20tlbb8adh8/D1 FT+DUGti7loLPiuw+c/8AmE8McG/XndSXidhaHWaUmVNYAzZW1QuvJ2bOs4lIe7jMXlICP OVo7aUHCY+EsqCdDGkC9FygqX9E65nGnear5+OpgzE/N+bDhHownhxjTwIwakMoNFuvDLs bu8bEf73sRhzRARC0NL5HXQZ2o81L3JADUvJuOtdDnhivHb7qZ6boDu0hmZl8FV2BjfM6n DW1EGn4LaS6mPMJzEdZbRsHy6gMzy60Qte2yUalBWT9o0Ub4JOuhvqdlA7giZA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725400027; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hyPJ40xTOzUcguhYJn+1V1WFij52cPc0WTRyVArN250=; b=LZi82RKpU7VjY1bfdyzKb4GhFhc7gurmeU6ws3uC9q4JY7782e4vSoUr3Trpp9dJMLoPEo mygnHy6oJ/6KM6LY9LT+h6t2u8bqsYvjijzhZCkp8fzAQkemIdHwPbEDtjXe8Hls8Hubti X4/uLJyi4gAuLZ7q3LEZ7ZxGaw3nkZ2UtWkAVtJ2uXKVE+TKO58Awh2lXOCVV+0C4Nib7J FUfhNN8BEN9ujOf3Ezw992Bnxfo3uiQaDbFxlMokeJr83UAQ/gh/noI8j3HukT4CbmNOJg S8v/y9HO7EvCGGcSOtO9YcxGxE6emf8qh4OlnLXjK0qTZEp3BHCuN71YrPqWqg== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Wyzjl1KJqz1GsY; Tue, 3 Sep 2024 21:47:07 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id CE0043C019B; Tue, 03 Sep 2024 21:47:06 +0000 (UTC) Date: Tue, 3 Sep 2024 21:47:06 +0000 From: Brooks Davis To: Mark Millard Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI 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: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> <02BE22BE-7E86-43D1-86D8-85A527625AD6@yahoo.com> List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02BE22BE-7E86-43D1-86D8-85A527625AD6@yahoo.com> On Tue, Sep 03, 2024 at 02:36:19PM -0700, Mark Millard wrote: > On Sep 3, 2024, at 13:32, Brooks Davis wrote: > > > On Tue, Sep 03, 2024 at 12:09:55PM -0700, Mark Millard wrote: > >> On Sep 3, 2024, at 11:12, Brooks Davis wrote: > >> > >>> On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote: > >>>> On Aug 30, 2024, at 21:26, Mark Millard wrote: > >>>> > >>>>> On Aug 30, 2024, at 20:33, Mark Millard wrote: > >>>>> > >>>>>> [Subject was retitled.] > >>>>>> > >>>>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: > >>>>>> > >>>>>>> What my test-of-building got was: No 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 > >>>>>>> | ^~~~~~~~~~~~ > >>>>>>> . . . > >>>>>>> > >>>>>>> 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 > >>>>>>> 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) > >>>>>>> > >>>>>>> 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 > >>>>>> /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= 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. > >>> > >>> 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--- > >> ===> The following configuration options are available for llvm19-19.1.0.r3: > >> BE_AMDGPU=off: AMD GPU backend (required by mesa) > >> BE_WASM=off: WebAssembly backend (required by firefox via wasi) > >> CLANG=on: Build clang > >> DOCS=on: Build and/or install documentation > >> EXTRAS=on: Extra clang tools > >> LIT=on: Install lit and FileCheck test tools > >> LLD=on: Install lld, the LLVM linker > >> LLDB=on: Install lldb, the LLVM debugger > >> PYCLANG=on: Install python bindings to libclang > >> STATIC_LIBS=on: Install static libraries (does not effect sanitizers) > >> ====> Options available for the single BACKENDS: you have to select exactly one of them > >> BE_FREEBSD=off: Backends for FreeBSD architectures > >> BE_NATIVE=on: Backend(s) for this architecture (ARM) > >> BE_STANDARD=off: All non-experimental backends > >> ===> 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 . > > > > 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 ' 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= arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sme.h \ > +_BE_INCS_ARM= 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.) I've gone ahead and added arm_bf16.h back in my latest llvm19 update. (I just realized I did something more convoluted than necessicary and will fix it in the next update.) I'm still not sure how a file in a list in cmake named aarch64_only_generated_files ends up on an ARM only build, but so it goes. I'll merge to 17 and 18 as time permits. -- Brooks From nobody Tue Sep 3 22:41:12 2024 X-Original-To: freebsd-toolchain@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 4Wz0wQ5kYHz5MZ8D for ; Tue, 03 Sep 2024 22:41:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4Wz0wQ3G5yz4GJV for ; Tue, 3 Sep 2024 22:41:26 +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=1725403284; bh=9mgGV/qxRXeZvETCCjuzo30Ss6tGb6cWemqHNNJa2uw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hU2IKXsq26GFownOGxDoA3SQtTuyTwebYxX3Itg99SkATh9/fuO/Rxh+FaRzbOB52/v2+1V11WaNhPmIvRRV2KFbPUvSrou3NFtSwjTTG6Vzf/UfKT+ertQCCS0BHUoGoXKkSPgcQ+631EIkR7AlT5PwclTD0GDW4UkTbZEttG9ih1113T0/3ifZAVWSbPGtZ4uVi7/p7lpIiPqyHEoUo68qkdTfYoBKJ2dYkyIjE3chOCEPxXiBRql0vz5tf9CLfHasO/ToyEAgeB+N0cFKYjPtrm1K78BvOQ4mcXlsMZxamPreT+2GEU1shwwy8fs9pcdz/27pIGJIz3XH4R6Osg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725403284; bh=IacsPinKSHX4PilqMIgdtIxQGBCv7xy1eRb3OtzD7VR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Bgx5gle9e0PZp3t+YOOJenn4iW50jOymKSnaGqDtPQADQJoXgR+e36rNANQC+i+0JX/C2od1mOM+7KRrp4poe1CDtY9HK+LudTtXhKckBRYJHQ3IBN4T6lVwG6y1RpjnPLkrLi06JDkZpwbPiZpYsq0HUgliouJRhsKoEHnh13e3+b15J/TLBDd8KlcGcUrMZLBiWwGFHa2VxbqaeoQTI/jNPL87sXE5luC6RxoaZFlbRubA12NXAOuhQBASRE52hEerCo3O0NFpnPFBKziPytLN7ku4jarFnjEDTbiNio3CvzZM5XwMy0kuzlssTtq0Z7MWMqbUuIJtzVRQEv4rUg== X-YMail-OSG: utUsOj0VM1mdQSm9EN59oC3X.JOFhqSZ.fsEOE7LCu.MhCXXqV2Vyg6ROblIn3. iX6m29SQVHjE6jIMz9ytGYn90NQRJ7dCdPVeKLKC9QPAFdCQzxi.TFdaZDJve58Fy4e27m2hjz8b YbXsqYTfggt1IvaCB4FKEEqEJl_kw9.L1bAljtpKdnGicWMy6eQ8wd.O62SYgOKC0Ub1AmsIWW2o iFNp8tGLBMU9xUoxujh3NHL5S_GHdzC..sFmuhlVTW1vs2xdh_cBXKRvUn.4MD_pT_PqJUuFO6Ru ccXBFmxjOsbRVFcbkmQ2Xyg5rDKyChGsM40MvupGGSIktvuqZhaS829NvEoCssBbNQryuuOrLRJK 7PNT0xahy55WT0_6SalQZ5.HkJ.NeysdOp5bPcYgaPC3dJLw4LJVs2HCVObe6nITRU4lERBRiWmz ZrqsEwwjglEEr5n.mwmpodBSi61QwnXQALAr5lu5DQnbbz.cTIN3nBsHwvQY.hdQIFSNm9iZutou Rdcu7BuaR50ypW3S7pUDstX6UuUrDOvSZPvGK3f1xDDk6ZMjqkssT1eTIkuNrzckoieGSq8MD6mN iwIn6OZaw8gBO4cZY9BTke3tSb9mBtabp7Ij7gcPEgK5vrzdy7Eg7JI_l3W5AAP8e2HSRTof1zNl x1RMx7o_Wx18cxMIRhec.XcX2o3L0boTYy.oeVWcMNa.nrk743POxOiq3XbUfSIIq8g7M_a_ftVi jcvX_l_6K5yVIC9WtdXpJ73Jcvi8T7wXwduAA.xkwR0XULTb0MgZm17m5OeUBgVM32Uoto0mOBun elYmNzwy8UC68Gmt_RPX_P7gKO8TT93rQ2BqSE7AT.UOydJhys.s8B1RVz9t_mlmDBagkxeWMpHT EAhp6TbnUOdEMoW3_FwDeARwXz8pnys3h3kg4s5Nss06uMh.A_A5TPgBwg.AsScX4gqm4SdtrWue SCzYvGyDzlPwgAXQFXq0uqTy6jtETh6yA9tfsmmx4xYey.G07J0wEP6wivsgo04PgyRDpyu739Eu 2gFSMGPAIZReWks9LoWbZf9aYsYt0xK52A0OQLvBDjmPAcn7JtLZ.8nEP7QUZB0hjwzHKHGAAd_W vL45O023wzB38DlLp1TOeYtPEGmaaP3v95huW9mFuaE5_ts2UG.4NjIpd29nkH2OxsXPItC8aVrZ bVAWOet9zlVZqJn3bYx2HG20UEzOr9qsc_pLq4z3itj7sA7ZRmBVqSQUVLvHqqibCesODHvMKv4s GagLateUC_9vBVRVzIQSUtQyCrgYu3HGdS316HaaYBQmwJQblcMgaCRgspTn2e4eT.uz8I7c70aA sK9_S4.330W5DRM9rWk6HXAyI1VSjq0onHf4Io6dfhB0JjxPKL2T3iVeHcHj.vTf4nuvpOo7NxYO sJsmkDl8zlalVG5VdPcdmfDxp0.esvhmVU.R8eprW3XkyzXfB3bptzfWbxyWNfJanrUSTuCoSQLV zz_RGA_cQ51DvCc3.SIUKXp9hg22ChdO.Amkf6yTf6P1jO34R1RNhlu9p_kl7E9E8NK8fw_YZu5m devQfrodEHmPi_wkXN58qyM4R3Kp8o4AMDex5M_elqoWQE4H_3bRQa9ss5LXjueSyiQ.azfob7F. JdN9qujOUIcojv2t6pdbv2Y9grir9dddZKfeD8o1Dl1FuTquv.xz3aBZ9YG1He1R8ydjnmK.1wV3 hwU4.YZ98qbUmddwKy0jbGcu.jXcE8nl5srEIRJG671OEqDP71NywL9vIhVShQ24CoUsRyiutc.L Y8yG5NKm8CccrF0LOLKDP2pHQdlN.bfWwlA0Z75HDX0C030037_Hw7mdCk1hMUSgSTw1y6yWBbF0 zK3CkTguHEqeDQc70KyKFkupyrh15tddDYjVGYSmfdzD6xS.HpxboGvgMaPgHDsUdKmdqCWiDeG0 .Bw89nk9jQEmYgKDxlc1YCUGFG9zRRKvV4z3ZALiTcctLPip4fODjwBqqB6ITswUGWt1IXyA7bjA sTBsBxySeL8wnGi8ky2GFZjgbww7tTASnBszVWYp8DVkjEl6y7VguI98C0unyKPzNoLMF6p_VCYO 0nIWA4bEOelqGXALllFyUCe6fZIHeyECktcCJf52oomwUDoHIEI.dOR1Y6fv8CPhdpsAg8lWsJtv HOJesG25rhs51iS1SwYmQpW_VnKSAJsHb55fsNKSFyyovT2XFv3fM9z9hiQZ8P7MHCNqXI.mu_.7 WLvKcT2kBi9lJrAp4AOrEAxMuYnHkrOTrNimgocjf X-Sonic-MF: X-Sonic-ID: ddee546b-0981-4fc8-8a5a-adb3644d2e5e Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Sep 2024 22:41:24 +0000 Received: by hermes--production-gq1-5d95dc458-dxlpk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ba3705a8c3afb2f4da41e83db7a9632; Tue, 03 Sep 2024 22:41:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@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: Tue, 3 Sep 2024 15:41:12 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <67D7CB10-48E1-4E4F-A632-087CF7B2ADD0@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> <02BE22BE-7E86-43D1-86D8-85A527625AD6@yahoo.com> To: Brooks Davis 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: 4Wz0wQ3G5yz4GJV >> . . . >=20 > I've gone ahead and added arm_bf16.h back in my latest llvm19 update. = (I > just realized I did something more convoluted than necessicary and = will > fix it in the next update.) >=20 > I'm still not sure how a file in a list in cmake named > aarch64_only_generated_files ends up on an ARM only build, but so it = goes. > I'll merge to 17 and 18 as time permits. Well, I expect that you were depending on an error in clang/lib/Headers/CMakeLists.txt . Details follow . . . clang/lib/Headers/CMakeLists.txt has: # Generate header files and copy them to the build directory if(ARM IN_LIST LLVM_TARGETS_TO_BUILD OR AArch64 IN_LIST = LLVM_TARGETS_TO_BUILD) . . . # Generate arm_bf16.h clang_generate_header(-gen-arm-bf16 arm_bf16.td arm_bf16.h) . . . Both ARM and AArch64 generate the file. Later (in the '. . .' text there is filtering via other lists of headers formed: list(APPEND aarch64_only_generated_files "${CMAKE_CURRENT_BINARY_DIR}/arm_sve.h" "${CMAKE_CURRENT_BINARY_DIR}/arm_sme.h" "${CMAKE_CURRENT_BINARY_DIR}/arm_bf16.h" "${CMAKE_CURRENT_BINARY_DIR}/arm_vector_types.h" ) But, DDI0487K_a_a-profile_architecture_reference_manual.pdf indicates that there are two BF16 features, one for AArch32 and one for AArch64: FEAT_AA32BF16 and: FEAT_BF16 That matches up with the clang code: 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"); } ( so: AArch32 is handled by ARM.cpp ) and 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"); } ( so: AArch64 is handled by AArch64.cpp ). That leads aarch64_only_generated_files looking to just be wrong relative to bf16. I'd expect that: "${CMAKE_CURRENT_BINARY_DIR}/arm_bf16.h" should have instead been listed in: list(APPEND arm_common_generated_files "${CMAKE_CURRENT_BINARY_DIR}/arm_neon.h" "${CMAKE_CURRENT_BINARY_DIR}/arm_fp16.h" ) I expect that this comes down to Target ARM being what supports AArch32 (and, so, its FEAT_AA32BF16) even for armv8. Target AArch64 looks to just support FEAT_BF16. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Sep 5 08:31:38 2024 X-Original-To: toolchain@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 4Wzsyy6Z7wz5VwXX for ; Thu, 05 Sep 2024 08:31:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzsyy4768z4hbV for ; Thu, 5 Sep 2024 08:31:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725525098; a=rsa-sha256; cv=none; b=eZkjyTJnZd/n0VVLckkzoMVCqUsPZmWCSF3G86eBUgoAXTKJ6W2yjgD09/QlKAQElaBacA dUnGPA6YT5ry7NoFzjJesPYLm2rzNagzb7AIZKGTxwcGbofkCBk2sFUhnJTVhiXhw2DpOd utd/GOKNuH+TR1ufqdZWAztmD70iyJ3jF+aQG8oZUJpiHwkOucmBpsH7RDxGVHmQcyku/9 1QDfD0piu+ysXFlmkTySM/BLsz5mPYWgDz85KQNwolajxYoavuBrhWYbs3VzyQ8H5h3XXL 2USDuXVUQWEtInBRvVDaEz5J4FwxtYE2GlGWNRKz82/hBjk73uY6xCdFF2U1VQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725525098; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3Rtsm+DQoqXwWBcQlqSBZdr222lGeAMDFOoUwuPEx5U=; b=pL/ZC1TnWOtQIV9hILo3Fxqmt+xjTUiAN4h+J7eq1bwUUiF1h0g/LI9DP7b1cBU1iCipq2 1EB5W35M1+22MCL1n7Omr0P9u9uzfcGh1DS8+DG+X6OJ+F46Tv/dqL2yiv9IF4WU3kQbnW OBydy8NUPoDnMMc5FYdzl++k15CzVXqoJjQi3+ZvaTpYp4vvzuVlNyOcrFDrgqYSapzNNn COwmhI3bdB9kY1yYQhCw0Wr0rymFQxBo9IhIMBLY04+g1b3HhoV7bo9hdogK2QPeos8dn0 f8D0Y2jBvbWxtVBxYQU6Y5cGkiWApsqkt1bAofLQjnKCyxPRa0qs9PZ8OjoTfg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Wzsyy3l2Kz11qf for ; Thu, 5 Sep 2024 08:31:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4858VcOs018231 for ; Thu, 5 Sep 2024 08:31:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4858VcCS018225 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 08:31:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 281257] base llvm csetjmp C++ header file now generates an error Date: Thu, 05 Sep 2024 08:31:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281257 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |toolchain@FreeBSD.org Keywords| |regression --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 08:33:21 2024 X-Original-To: toolchain@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 4Wzt0x57bvz5VwbB for ; Thu, 05 Sep 2024 08:33:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzt0x35sqz4j5Z for ; Thu, 5 Sep 2024 08:33:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725525201; a=rsa-sha256; cv=none; b=pbZt8tmhucva1wWRwBwCaGJYPdoGbYEBol9+7A7L47EFtatQFUFAUevjv0w2TAbTh9ZUxH K5z+iYlf2syDYBOspYP694lnbZeGWSaF+7NltAtmSPdnyno2yckB1TUJOnwdjviEJWatgu 9fllBeGi/TG20ZHi31JDKDFoz4fyvnfJ1iauvNsg5pLfYGZrm06GX36+ROoT1ciXv84seY wl02E7kd0IlQ/JGU6FEYtUl+6QbQxJa5x+e/8HyuFT0ntLGj0WXZ8AEN+p5FAcpJj8Dy4U 2uEJfGae7CLknR0Sz1g0OPtNa6lO6R9+SwCUtgkbJnJmdnGLXuOHzvdWtWXpSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725525201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E0RRzkjSrPw//O+deVoqwrhK/mdeSgHhJNM2OnmDWzw=; b=pdggVqttZ9j2qqdeyXX7vZo3qbsrgS0amnxUyNjxas6pMP1h9teZRLmh6prnPBcaWKp4nC TWoXxr7TqsHkq3kZJ45suw43fmome2lEy0zikjrhbX0MNWxM6O/kMeF713x6XneKvXQWNR 32kI2xmnkzmcCksloJ6+eFgafAaa0jbYqHiL9yuzjei+bu4QVc28fAe92/GhgJBRu7kPaQ kWaQbN9c9ZAu27kd0+l8k9IEQbKzoVXGrjc7yBXz+FchoZpYou+fi0dTnHeRXWmKfYntal HHNq0ZW3c98PodE0exiSur03kCExLqmUjW4EOEIgQwy7lNfbKeLvFTigixgKFg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Wzt0x2d9fz11nY for ; Thu, 5 Sep 2024 08:33:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4858XLLT027403 for ; Thu, 5 Sep 2024 08:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4858XLfV027402 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 08:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 281257] base llvm csetjmp C++ header file now generates an error Date: Thu, 05 Sep 2024 08:33:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281257 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed CC| |dim@FreeBSD.org --- Comment #3 from Dimitry Andric --- Duplicate of bug 279692. *** This bug has been marked as a duplicate of bug 279692 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 08:33:21 2024 X-Original-To: toolchain@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 4Wzt0y1Ntpz5VwVf for ; Thu, 05 Sep 2024 08:33:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzt0x5fcLz4j3f for ; Thu, 5 Sep 2024 08:33:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725525201; a=rsa-sha256; cv=none; b=tY/p9r2oEdwHEk3lOT6VwxutuMFci81aO1H67SeKcfc+KCvgcwokHkTNpQIMMzuzb1mHJQ GmiQyRdRIfYr5igC0MC6zhBRBXvpiNNTbqwJI0rT24Ty43krO6ES+UmSujL/ACxZGGf+kU rYfezTlKo4koHiILvAbwdqdgwcUtaShLYshG7kctPjcWoGhKIa9U0746jH3TCBJVIs1/A5 9hnOjdcw9aPrWZ2GOB2DE6X+UgEOXjlofNdauUVQ50dqa87OQeLeUM0o3mXIGOs0DzImCw xaYlwDEFqx7mkoZ2+tXjhmhiCn0mpfWoGtPGw5DghzA/u2ciEMcHgyxNCxgW5A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725525201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kiIRHoLsTKK5jxhO6akzl8pHDJEUisLQqhcmGu9WSKs=; b=WQsUHl2DhWA0o8eY0TvpWKLBcVjaoyZfPVNcsmG28tl6UwU4Zbm7itv1KjDkm1KgdrRw4o GKjqhOmnITf50gzVbYGZ9PO0TrGQyVFDqNKktrsfZQMQzAbLRddpeVPPAoexkSlDrZcL0Q Gdzc36Qtd/5GbaAr/bFUBhfM6iZRD3kV3d9bEDxPLe305jf2RAxbYBvhgrupvz96H95np4 Ns4YwaIwATo3TLFmoXpt9pTZAFRwZWYVPX+DRkpbv0f9JKiTFloJ/TZWr/J07ddW9VwIoF P/Y3OtqPqGGsTRfQuDnMaEajjVdP7usa9YP6VuaSNAK2IRONFytXxxGvHDGrag== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Wzt0x5BFHz122f for ; Thu, 5 Sep 2024 08:33:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4858XL8U027430 for ; Thu, 5 Sep 2024 08:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4858XLJs027428 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 08:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Thu, 05 Sep 2024 08:33:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bobf@mrp3.com --- Comment #4 from Dimitry Andric --- *** Bug 281257 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 18:55:35 2024 X-Original-To: toolchain@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 4X07pv6vdMz5TddJ for ; Thu, 05 Sep 2024 18:55:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X07pv4m3Qz4QjB for ; Thu, 5 Sep 2024 18:55:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725562535; a=rsa-sha256; cv=none; b=bpowQHNMRRigaivFf6GS84zjqu9bWxdyl+WMk4G4Pf88Fe9+HaXjxPc5mQCbkkVjr+lEDO vXL2AoM8IUuUj/1E46pd7A/ZC7AMDpuD1HBFomPDbB/l85dRxRgEZzQDTf7YEeXOkAv8f/ 5YA8dkhqBtLdc1zqkXOZNf14hb7hRycd063MnqcaMgj/VCKPsdfuAQ6bhzFEzwFHl1/mk7 K7C6CoPXHCW/UACYcS9GaTmhwAANHlDE8xG28KLKQXENaH2xx3spkm8p/1s5PiGrwUYCCQ fboUYhxCk3ThBE7kzPYZ9xd/LSl9E/CStgm/aW1peDe2uePjp+oBwEnNYNq6tA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725562535; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NPnWdkLoTn3vsRUIMsRpBK1xg0i5KyDyvI74uO2rThw=; b=hYQqVun2wR6r2WonmjX/kHfJvmVzzM4AZ610bh9S5cKAZdejx/wddKfqemeM389zD4xKjY 5jmkejyNhMd4HqcZeb3guNHXY8UHwuKOqgGWGOFcERNtVMSXno7E0+uxFFDXQZfZcf5po8 Mc167WRzvtTpkp6FPgR3dfC0AoTqG5FgaefloD2hNstdxLLSJ0gHpJUm5nix06Iw5hFuaA RHDvaTzhYWOz7ew3cVFuY0quujrVHDI9m7SxXsDjys6lRz8gPE21i5GkvI07sayDJNHU8Z VUlLzgYeYD6VfAFLRPKFEG5VnS2xrvGVCDhdsMT8zJ2b6nWAC2RMLmHnaIEB/Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X07pv4DCHzL0c for ; Thu, 5 Sep 2024 18:55:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 485ItZgq052982 for ; Thu, 5 Sep 2024 18:55:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 485ItZNh052976 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 18:55:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Thu, 05 Sep 2024 18:55:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bobf@mrp3.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 --- Comment #5 from Bob Frazier --- Thanks, deleting the above mentioned file appears to fix everything related= to csetjmp please add this info to UPDATING regarding setjmp.h and csetjmp also there are two setjmp.h files in "/usr/include/c++/v1" - shouldn't BOTH= be deleted? (/usr/include/c++/v1/tr1/setjmp.h is a symlink to /usr/include/c++/v1/setjm= p.h) NOTE: in some cases, like a massive ports upgrade, using "make delete-old" might not be desirable until after many ports have already been re-built. I did not use 'portupgrade' but it could very likely break something (so I do this step last). But this is a nit as long as UPDATING covers the topic, I= 'd think. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 19:31:27 2024 X-Original-To: toolchain@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 4X08cJ106Tz5TkFd for ; Thu, 05 Sep 2024 19:31:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X08cH47H2z4WJf for ; Thu, 5 Sep 2024 19:31:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725564687; a=rsa-sha256; cv=none; b=AKFut56DtSj+ZoSLs9id+qh6+4wB3Erbmww9IyRRG4aHvIyvjKiKn6SJMHgtbY23bGeFkB yVoPyOcfyMd/XVVk0q1vijEubhF1LKYs2LzQwxliyK83EW4eBe00dJ0coOAkgHUogF0qLz 0KnRU1Ij3qlXSukyHPsL/IKBgBcM0uqCiUoUsL1xZlJnjlMgqexbRhHCzy48ppXD877Z9y b1BAbuK7VF8PfkG1BFMRjDFTjstQ60PloDgxqJD4i2Zcs8V9W7bmd/OywAqsrigyLwo/eN WVXvHVNQ8H7knA4LHrd9kVBDBUMZXxV5XK4kWUJb6AIVu36HOmDiyVx1c5q7YQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725564687; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SlNGFaKT14y3IKOSaSotWOUT3IHGycXRloOi4cjdLrU=; b=rzHuhy4EAh8nWTUj4wYoCOe59R3yLn8ewJTg6/xbgXmVoYA2N0WXu3US4SCP4jLAR7LHu7 hh8XE6fEY5Vp2d2CqV9PCTZ/WJ0Egth+NXVDIic7QP3gy9jaZVppb3o7HlV0Bt/tcFOG8A DAbc7e7tVf+rqWjzNWwFWYqb0FRGsL3/1zi8GJnrd/bj5/JDgQpxybgrp5vHIoy7TzbnUo A4/sUIrPTJGn6/dLJCAuptKGJlzA/hpX71zjVY7qBNQ1a+kC3mKsvnsGMk424K5Rapu2Tf 01XbFUCekeRZ7LuChoNrnsV/eFeyer2+518LX6AAvK4wSj2Iq1l19vVpVrl1vQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X08cH3l5WzLH9 for ; Thu, 5 Sep 2024 19:31:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 485JVReY011528 for ; Thu, 5 Sep 2024 19:31:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 485JVRZD011526 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 19:31:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Thu, 05 Sep 2024 19:31:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 --- Comment #6 from Dimitry Andric --- (In reply to Bob Frazier from comment #5) $ grep setjmp.h ObsoleteFiles.inc OLD_FILES+=3Dusr/include/c++/v1/setjmp.h OLD_FILES+=3Dusr/include/c++/v1/tr1/setjmp.h Both of these are in ObsoleteFiles.inc, the latter has been there for quite= a long time, since the tr1 directory was cleaned up. Everybody should run make delete-old after upgrading, this is the only supported mechanism. Adding notes to UPDATING might work, but if people don= 't follow instructions then it might not make much difference. :) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 20:02:02 2024 X-Original-To: toolchain@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 4X09Hb2cSqz5TnKp for ; Thu, 05 Sep 2024 20:02:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X09HZ61Ptz4dqc for ; Thu, 5 Sep 2024 20:02:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725566522; a=rsa-sha256; cv=none; b=YjS1Dc4RBiTB0KRJMdarkD2W0C9M/VzgkJIi7HlP/2qBeT++N3/6DtgyCND+ih/iBnTD8r YdieDsGFTGDudSOFYQ9Jm/NaPJV2ZGQvBFkdKnImffdgq1CS3B3dMyKaaSkdhy3me5/das OU1rSKZflWSljrJ/TWthQheRtF+Idmy8ivDxDbPk7poH9nYRsK0jyNsflUaefFjLHWhn14 QJz13WyGwEir8TZLv2d7a71WnfUaRgWYcGcsX126cMXHu1DhpPYnOa5bUnDm2ns/1Tdvzv 54AYrytXjATCb6H6/ayU3fwSYSWjbkzSFCmuB5q2HOPtnCgJbHeSSx0przIPvw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725566522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NNw7lj0Hm4DFMKZJIDKrcstBtJ2dVQ4hXmGpdIco+yY=; b=GPu7V6pCV1Ya10JbTgPpQqw+kH+4ihUuh0rWP8AfnK0FMSeTlOUcg1DzT0yFz+aJIapulS BK7VHSZmIBL07Z9VtRZJQmSfU//GmMmCCWWdMp07l1EjpzUTIRic4mUIeTnIoEOltTgbMS 3/sN5hfv2hWnjYSabzNGb92rp2PbbqyITrXsYCj1af3yR9rxQo0LsoWrcDHFL4QiwLNg8Z +XatHbnnz+beGdx2JBbJlvrJywWgwZWYsv+2CkTxAXp8kaM7S3RXk6IU+2GaHNQjpS8w9m PTdm+MgAGThhkBlkmGIGOe+mbGIOsApACLX/A87XtDbEcPam7wzefyCTMZnGog== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X09HZ5YnVzLyK for ; Thu, 5 Sep 2024 20:02:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 485K22Us047922 for ; Thu, 5 Sep 2024 20:02:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 485K22BN047921 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 20:02:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Thu, 05 Sep 2024 20:02:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #7 from Mark Millard --- (In reply to Bob Frazier from comment #5) QUOTE NOTE: in some cases, like a massive ports upgrade, using "make delete-old" might not be desirable until after many ports have already been re-built. END QUOTE Avoiding running "make delete-old" leads to the risk of silently finding and using out-of-date content in some of the upgrade's build activity. Such can make it harder to discover that there are problems to fix to be sure that the right content is used. "make delete-old-libs" is somewhat different for the criteria relative to keeping programs that do not yet have updated installs operational (still using old .so files and such). "make delete-old-libs" is appropriate after the upgrades to versions that use the newer .so libraries are in use instead. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 5 20:12:11 2024 X-Original-To: toolchain@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 4X09WJ3Zmhz5Tpv5 for ; Thu, 05 Sep 2024 20:12:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X09WH70b5z4h2r for ; Thu, 5 Sep 2024 20:12:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725567132; a=rsa-sha256; cv=none; b=iWhHTNFPrFICNPTcwV4lpNr00ZAJ1PK3suSw+IF6beWpO2qXt8WO9YhigHJYdt74LekSbN LxaRDeG0uFMLyorP+C5qVhh2TwfRWWGPU9JVMsLN4A8V9CsxE2ZIrSVb8Rcire+5ZsDlQp w41TehIpg7sZIB/X+ftDUgJWzaui7s+fNIeKU98JTcOKegKGr5j6FPZ5F97f9W1TKP5iYg srLFFiS9cdwawEwtPxZvT+lHOLM0vxNHS0KMkgUR74YDlpKTfz/klGf9xcWo4R7YIlkMWo +h6QZHtTRqIuMrmbu31kFJ/dNPF7OiAvBWRWnF8G7PYU6ayK7oEDbJ4MUjv6HA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725567132; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wwzRKA1I9pgxjqqBmQYzRB3NZkNEGLF2T6LIv6yzhUs=; b=hSY5lrmKpZjtaLhW8/IyGTX01cIkQUVPez3nqXjnLSZi+7dReey/kfsljRE/IBHyKj4A2W vx4mYX9X8Q9NujVGBF3ba9T25ehwqqxtb++WSvE498Tk93IMiU3FK1Xa3LYz1XKeSdP4Ek gVO7nMCURi2Rda5GvtBHB5E37wdP1GFn3KoQsXbiANTMDjgFcL2o2br6QgbcRi4fK0He4/ qyt49/1bu31wZ1cfBHYnp731Wzwz0g8iePZJ1kh2X9qGCgNHgSzYsSEzUXEwkCv53g36R0 mKjcPjI5gpk0+sB5jgiokPWLJwPyAiZnxpwQNvylITvOIMIqoDNAyy7HMsiV6Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X09WH6c3bzMx3 for ; Thu, 5 Sep 2024 20:12:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 485KCBFP096794 for ; Thu, 5 Sep 2024 20:12:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 485KCBsb096793 for toolchain@FreeBSD.org; Thu, 5 Sep 2024 20:12:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Thu, 05 Sep 2024 20:12:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 --- Comment #8 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D157802238b5aa7722aff40317fe6d05f5= c975d71 commit 157802238b5aa7722aff40317fe6d05f5c975d71 Author: Dimitry Andric AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric CommitDate: 2024-09-05 19:58:51 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days UPDATING | 7 +++++++ 1 file changed, 7 insertions(+) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Sep 8 07:55:16 2024 X-Original-To: toolchain@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 4X1j1c5xM2z5WJ22 for ; Sun, 08 Sep 2024 07:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1j1c4pmNz4RP1 for ; Sun, 8 Sep 2024 07:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725782116; a=rsa-sha256; cv=none; b=wtTPh7HW+Q1qlGyf6c4rmoZi7pqVwyRarzuhh+Fcmlv70OQRqA56kyXd3mTZVzeqdPr/4R EkvJ0DRro103aM6N/BFRLGZGVIR5JdkvEhwae5+elvTEqEetDdT/jupjw0PVPXwN4DKqaE qCXv4Utn7ubl5AzX+YHyUuCx8g6PLEhhBvAu8rO4XBDWzlwX4tjFAVrsoUZE0eOnr4Q3/+ z99JTa8imiUtYS6+HR0RDel5gM1zhhgwbqvcBEDPzdcPfM1b9gLSdt0Ta+JnKCVBjR7Qjw xM0O26uWVq7p2pgn+QuTSF2W/d3z7Wrd2YNolPTwxDqdDOABR9/ab3mdpgblJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725782116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hwYbxCSX7LiJ3Lhpn8MPOyCcAkbs/y3ddMnYUoWr93I=; b=mFdMsyjRx4fyqhEUm4YmWLsZXnY9Gfb/Fq4MRjbSBwjNHIRg4dPqyatTHzhxASHResNjr3 zeN6NOll60TjVP884JwcnURGfPz3H+m3Xx5Hkeiqw1MeesULoWD/tvwxttKhM5aepNjJqJ SPsHTQnS0rlrCEs42w2z0CGOPUEeRnnm972d9oY9LZMpzURCfS0j6Un6DxQZ/6OmYZkq6b yo+Czb0s/VRh03SikFWhX189n21LqNU14n3XrAzSX40TLkqvt/2F1o9gJX0cVDP2zKL40z zZUlIoYCn8Tf4niJEA/atqTJjUxUlzc/krWVElUEyyxXT4C/1SRLcUO/84xjsw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X1j1c4QKZz19G8 for ; Sun, 8 Sep 2024 07:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4887tGZi026789 for ; Sun, 8 Sep 2024 07:55:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4887tGo1026788 for toolchain@FreeBSD.org; Sun, 8 Sep 2024 07:55:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Sun, 08 Sep 2024 07:55:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 --- Comment #9 from commit-hook@FreeBSD.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D28ff3ab2ab064224cd1fc0885040c3c47= ed5ef4d commit 28ff3ab2ab064224cd1fc0885040c3c47ed5ef4d Author: Dimitry Andric AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric CommitDate: 2024-09-08 07:48:57 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days (cherry picked from commit 157802238b5aa7722aff40317fe6d05f5c975d71) UPDATING | 7 +++++++ 1 file changed, 7 insertions(+) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Sep 8 07:56:20 2024 X-Original-To: toolchain@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 4X1j2r6CbPz5WJDx for ; Sun, 08 Sep 2024 07:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1j2r3Nypz4S3m for ; Sun, 8 Sep 2024 07:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725782180; a=rsa-sha256; cv=none; b=gL2EiDVdHtcsGNuWEjnGyte94aXVNRCcv/vSJFBwwSH3wypuyCiPCXfr5dVQlTjoLoExAb SqNoIBM+yFuCIcWkis+VjLx+zF5m8KP+6RJLvxEgVLUB+I51GSw/KeevSV/6UllYzcVvrL h3qKIrmE0dzsfzh6gP2KcyR/9zSba4OtQEsP9Q+0ULt4vrAxA6XjiVorBzP48oWCZhQ5SF tgDxs6yxF/eSik5NkIuH7ufaKOQU+jtbXVv73R0o2Ej4XIpQXsCRelPey2wfGrXzeJLUsY CRyB5egA99WUxp450zamUgcwvoEb1WAOVKLDAg8e+JJMZaxj9rZ9f8mM1Ooc4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725782180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bzkD52tzwx5ThNveOQzWCTUQXRjkoE84SpzsYd0M3wA=; b=o8xVD27KopluAs4SM5DT9LqLctzoG6uOBaGgbzKIFkySgVsOA08b2B3pJi9zQHhp+hQdF9 TAkUmEbfGdPd5dqRGGGSO7omA0Q0Qp0QktJpE7TLe5m30UzEapx8gJiHNHoTMOLW0E+v+X jMlPQTuH5OhyWVIo6hcQAdHjv/Qp/hIX1ZjGmxdhZ4FNEL6+QfDY/sKLB5GpJo1GlSaF7H 2UA82gHXxa1p5GoUUd7jLOrdaT1rsf6U0x9x5EBL+9izwC+AyiWtHythD/aaewEJ+sfzAD t/l6boKlK6SILiGHoQaCpA6+SOgOk13Jzj5620zTaz/17ydXRWNhdQdBEAO+ew== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X1j2r2zkrz19v8 for ; Sun, 8 Sep 2024 07:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4887uK53030222 for ; Sun, 8 Sep 2024 07:56:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4887uKJt030221 for toolchain@FreeBSD.org; Sun, 8 Sep 2024 07:56:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s " Date: Sun, 08 Sep 2024 07:56:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279692 --- Comment #10 from commit-hook@FreeBSD.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D6b147f693b91f16db7ba6193611f6f4d2= ed762a5 commit 6b147f693b91f16db7ba6193611f6f4d2ed762a5 Author: Dimitry Andric AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric CommitDate: 2024-09-08 07:51:37 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days (cherry picked from commit 157802238b5aa7722aff40317fe6d05f5c975d71) UPDATING | 7 +++++++ 1 file changed, 7 insertions(+) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Sep 8 21:00:20 2024 X-Original-To: toolchain@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 4X22RT36dDz5W6ck for ; Sun, 08 Sep 2024 21:00:21 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X22RS6fw4z4PHF for ; Sun, 8 Sep 2024 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725829220; a=rsa-sha256; cv=none; b=xq0gWcZe8k3/BPD9Gj8XG3kqjSXvFcBxNzyN5Z5t8gvMaN8V9ii4jhA0WLraEcNnJUP4Ks LIgCjwm8p1pk5FN2L/Y26TdBJ0vxzeydGl9C6zkuWriu2vJC1K3uKkggHC6z45td+8+Kro 6PPHVX3T07KkBQr1l2D0t69MHyj2ulYqr0Te+4ckBkjPhZ1Kd5HVZKz+VHGbt9c34cYehb UViGAm5r5p8Dsu4RUopuaUKVw1S5y1U+foOVEmB8xYZVUxedruA99rVWfwOTU6ejIN8IkH 6JuuX4Ez78fDa++qfZpnD0OTvLDPinS/B5jUg76K0/wzUNlRCiPhFbAHVstAqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725829220; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Kx63FqG1SrR+ztczEelNuP6xrbFhyylXcnZ2vlRa2Vg=; b=OFpf6R3is/xCtPblZCJHXlI8IVjB9JKVRuXClSjZpK7DfVGl8BJXlS2u9whYz1rbmSq6+v B7Pzfqc6n1ZMCek8qOTjy9t745fcSXpHW6GuKyw9yPRoJr/lxyAbRsHPxZPpRrpgmFawCY quPQA2B8qxNtIs0l5FbGEK0G/k2UVYokCCp2Sg1zg4W51FH/GVq3jGE8eeo5UgoB53Lm8y fKiTMuIEsIjgNzzIcAsIraRaU7DZun2bcL16iiFCBuHM3EUMFzLK9GitfO0ZP45CBaoyO1 BGnJqLCOixqw2/+f81ffg3Gryhnwbjh+URHDmtopK5ewPDFTmQ5H9PpszpuWPg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X22RS667czbDg for ; Sun, 8 Sep 2024 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 488L0K3M069826 for ; Sun, 8 Sep 2024 21:00:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 488L0KtI069825 for toolchain@FreeBSD.org; Sun, 8 Sep 2024 21:00:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202409082100.488L0KtI069825@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: toolchain@FreeBSD.org Subject: Problem reports for toolchain@FreeBSD.org that need special attention Date: Sun, 8 Sep 2024 21:00:20 +0000 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17258292206.0DFadEB.65988" Content-Transfer-Encoding: 7bit --17258292206.0DFadEB.65988 Date: Sun, 8 Sep 2024 21:00:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 236165 | crash in malloc with ld.lld and -Wl,--export-dyna Open | 261341 | clang-13 runs out of memory on the port math/open Open | 263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd Open | 271624 | emulators/qmc2: clang crashes during build on {12 Open | 192686 | Segfaults using combinations of -pie -pthread -lm 5 problems total for which you should take action. --17258292206.0DFadEB.65988 Date: Sun, 8 Sep 2024 21:00:20 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open        |    261341 | clang-13 runs out of memory on the port math/open
Open        |    263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open        |    271624 | emulators/qmc2: clang crashes during build on {12
Open        |    192686 | Segfaults using combinations of -pie -pthread -lm

5 problems total for which you should take action.
--17258292206.0DFadEB.65988--