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 <brooks@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
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: <ZtdRqxBPukxcOkaz@spindle.one-eyed-alien.net>
References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com>
<E029410D-1964-4C55-8B2D-0427C43B4ABA@yahoo.com>
<D74514BA-9071-4F29-96F5-42AD6EC2B6E4@yahoo.com>
<DF65D496-D1E7-44B6-A04F-EADA1DE29817@yahoo.com>
List-Id: Maintenance of FreeBSD s integrated toolchain <freebsd-toolchain.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain
List-Help: <mailto:toolchain+help@freebsd.org>
List-Post: <mailto:toolchain@freebsd.org>
List-Subscribe: <mailto:toolchain+subscribe@freebsd.org>
List-Unsubscribe: <mailto:toolchain+unsubscribe@freebsd.org>
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: <DF65D496-D1E7-44B6-A04F-EADA1DE29817@yahoo.com>
On Fri, Aug 30, 2024 at 10:05:06PM -0700, Mark Millard wrote:
> On Aug 30, 2024, at 21:26, Mark Millard <marklmi@yahoo.com> wrote:
>
> > On Aug 30, 2024, at 20:33, Mark Millard <marklmi@yahoo.com> wrote:
> >
> >> [Subject was retitled.]
> >>
> >> On Aug 30, 2024, at 16:24, Mark Millard <marklmi@yahoo.com> wrote:
> >>
> >>> What my test-of-building got was: No <arm_bf16.h> include file found and
> >>> no OFlags::TMPFILE found (OFlags:: was found, TMPFILE in OFlags:: was not):
> >>>
> >>> In file included from /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.c:43:
> >>> In file included from /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.h:3434:
> >>> /usr/local/llvm17/lib/clang/17/include/arm_neon.h:37:10: fatal error: 'arm_bf16.h' file not found
> >>> 37 | #include <arm_bf16.h>
> >>> | ^~~~~~~~~~~~
> >>> . . .
> >>>
> >>> error[E0599]: no associated item named `TMPFILE` found for struct `backend::fs::types::OFlags` in the current scope
> >>> --> /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/syscalls.rs:144:32
> >>> |
> >>> 144 | if oflags.contains(OFlags::TMPFILE) && crate::backend::if_glibc_is_less_than_2_25() {
> >>> | ^^^^^^^ associated item not found in `OFlags`
> >>> |
> >>> ::: /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/types.rs:203:1
> >>> |
> >>> 203 | / bitflags! {
> >>> 204 | | /// `O_*` constants for use with [`openat`].
> >>> 205 | | ///
> >>> 206 | | /// [`openat`]: crate::fs::openat
> >>> ... |
> >>> 333 | | }
> >>> 334 | | }
> >>> | |_- associated item `TMPFILE` not found for this struct
> >>> |
> >>> . . .
> >>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)
> >>>
> >>> . . .
> >>>
> >>> error[E0599]: no associated item named `TMPFILE` found for struct `backend::fs::types::OFlags` in the current scope
> >>> --> /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/syscalls.rs:207:32
> >>> |
> >>> 207 | if oflags.contains(OFlags::TMPFILE) && crate::backend::if_glibc_is_less_than_2_25() {
> >>> | ^^^^^^^ associated item not found in `OFlags`
> >>> |
> >>> ::: /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rustix/src/backend/libc/fs/types.rs:203:1
> >>> |
> >>> 203 | / bitflags! {
> >>> 204 | | /// `O_*` constants for use with [`openat`].
> >>> 205 | | ///
> >>> 206 | | /// [`openat`]: crate::fs::openat
> >>> ... |
> >>> 333 | | }
> >>> 334 | | }
> >>> | |_- associated item `TMPFILE` not found for this struct
> >>> |
> >>> . . .
> >>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)
> >>>
> >>> . . .
> >>> = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)
> >>>
> >>> For more information about this error, try `rustc --explain E0599`.
> >>> error: could not compile `rustix` (lib) due to 2 previous errors
> >>>
> >>>
> >>> For reference:
> >>>
> >>> # uname -apKU
> >>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #8 main-n271819-5cbb98c8259c-dirty: Fri Aug 23 22:06:47 PDT 2024 root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500023 1500023
> >>>
> >>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/
> >>> 87a38a839ab8 (HEAD -> main, freebsd/main, freebsd/HEAD) net-im/dissent: update package description
> >>> Author: Jan Beich <jbeich@FreeBSD.org>
> >>> Commit: Jan Beich <jbeich@FreeBSD.org>
> >>> CommitDate: 2024-08-24 18:30:01 +0000
> >>> branch: main
> >>> merge-base: 87a38a839ab83c2def100a0975a7afb29e873cf2
> >>> merge-base: CommitDate: 2024-08-24 18:30:01 +0000
> >>> n674987 (--first-parent --count for merge-base)
> >>>
> >>> But firefox was updated to use: nss>=3.103:security/nss to match what was
> >>> available.
> >>
> >>
> >> Using devel/llvm18 instead got the same.
> >>
> >> Looking inside even a /usr/local/llvm19/lib/clang/19/include/
> >> also shows the arm_bf16.h file is not present. By contrast,
> >> for an aarch64 context:
> >>
> >> # file /usr/local/llvm19/lib/clang/19/include/arm_bf16.h
> >> /usr/local/llvm19/lib/clang/19/include/arm_bf16.h: C source, ASCII text
> >>
> >> Looking quickly at more llvm* shows:
> >>
> >> # grep -r arm_bf16 /usr/ports/devel/llvm1*/ | more
> >> /usr/ports/devel/llvm11/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h
> >> /usr/ports/devel/llvm12/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h
> >> /usr/ports/devel/llvm13/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%%LLVM_RELEASE%%/include/arm_bf16.h
> >> /usr/ports/devel/llvm14/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
> >> /usr/ports/devel/llvm15/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: `arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: `arm_bf16.h` immediately before their own typedef:
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: #include <arm_bf16.h>
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: Since `arm_bf16.h` is very likely supposed to be the one true place where
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << "#include <arm_bf16.h>\n";
> >> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << "#include <arm_bf16.h>\n";
> >> /usr/ports/devel/llvm16/Makefile:_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
> >> /usr/ports/devel/llvm17/Makefile:_BE_INCS_AArch64= arm_bf16.h arm_sme_draft_spec_subject_to_change.h
> >> /usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64= arm_bf16.h
> >> /usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64= arm_bf16.h
> >>
> >> llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more).
> >> llvm1[789] do not.
> >>
> >> I wonder if:
> >>
> >> https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=778e212f234a825c5e19612df4be2e8f838cb024
> >>
> >> doing:
> >>
> >> -_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
> >> +_BE_INCS_ARM= arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
> >>
> >> was correct. I'll note that in an armv7 context:
> >>
> >> # find /usr/local/*/gcc14/ -name arm_bf16.h -print
> >> /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd15.0/14.2.0/include/arm_bf16.h
> >>
> >> suggesting that gcc14 considers the file as not aarch64 specific but
> >> as armv7 compatibile.
> >
> > I got that wrong! arm vs. aarch64 have different source files with the
> > same name (under different paths):
> >
> > gcc/gcc/config/arm/arm_bf16.h has guard test: #ifndef _GCC_ARM_BF16_H
> > gcc/gcc/config/aarch64/arm_bf16.h has guard test: #ifndef _AARCH64_BF16_H_
> >
> > (More content is different.)
>
> As for llvm*:
>
> clang/lib/Basic/Targets/ARM.cpp has:
>
> if (HasBFloat16) {
> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
> }
>
> clang/lib/Basic/Targets/AArch64.cpp has:
>
> if (HasBFloat16) {
> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
> }
>
> which suggests bf16 support has 32-bit support (even if it is armv8
> 32-bit). Looking for AArch32 state in:
>
> DDI0487K_a_a-profile_architecture_reference_manual.pdf
>
> it says (via the AArch32 column of a table):
>
> BF16 Supported if FEAT_AA32BF16 is implemented.
>
> Looks to me like the removal of arm_bf16.h for llvm target ARM
> was incorrect.
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