These tests weren't run on x86 until CI grabbed them. It turns out,
there's a sign extension bug that surfaces on x86 with char being a
signed type.
NetBSD unearthed this when they took and improved the patch, so just
grab their solution until we get to merging in the latest version of
the test.
Reported by: CI (via ngie)
Fixes: 2f489a509e ("libc: fix some overflow scenarios in vis(3)")
It was originally in contrib, and moved to usr.sbin in 6692aa840c1f; I always thought lib would make more sense but never got around to moving it.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D41504
Update Intel irdma driver to version 1.2.17-k
Notable changes:
- pf-reset handling improvements, including fixes in communication with if_ice(4)
- avoid racing when handling various events
- adding sw stats sysctls
- hand over pe_criterr handling from ice(4) to irdma(4)
- debug prints adjustments
- fix crash after changes in irdma_add_mqh_ifa_cb
Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
MFC after: 1 month
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D41425
Highlights:
- Some style fixes
- Bumped mbbuf in istrsenvisx() to MB_LEN_MAX to avoid VLAs
- mbslength cannot go negative, so make it unsigned
- Further bounds checking & fix an additional overrun, with dlen == 0
- Avoid duplicate call to wcslen(start)
GoogleTest 1.14.0 now requires C++14 to build. Change
`googletest.test.inc.mk` to reflect this requirement.
Adjust the build integration logic to handle the new version of
GoogleTest (add/remove headers/sources as needed).
Tighten down warnings via `CXXFLAGS.clang` instead of ignoring all
warnings. Some new warnings snuck in after I did my last round of fix
submissions upstream.
Also address some overlinking added in the previous version import by
removing superfluous libraries.
===============================
Expect WhenDynamicCastToTest.AmbiguousCast to fail
This change reapplies the expected failure from 1.10.0.
Ref: https://github.com/google/googletest/issues/2172
MFC after: 2 weeks
Reviewed by: asomers, emaste
Differential Revision: https://reviews.freebsd.org/D41399
Merge commit '8ef491440fcaec96f899d73e08873426c78583a4' into googletest-v1.14.0-import
The previous incarnation of this would call wcrtomb() on the destination
buffer, and only check for overflow *after* it's happened.
Additionally, the conversion error / VIS_NOLOCALE path also didn't check
for overflow, and the overflow check at the end didn't account for the
fact that we still need to write a NUL terminator afterward.
Start by only doing the multibyte conversion into mbdst directly if we
have enough buffer space to guarantee it'll fit. An additional
MB_CUR_MAX buffer has been stashed on the stack to write into if we're
cutting it close at the end of the buffer, since we don't really have a
good way to determine the length of the wchar_t without just doing the
conversion. We'll do the conversion into the buffer that's guaranteed
to fit, then copy it over if the copy won't overflow.
The byte-for-byte overflow is a little bit easier, as we simply check
for overflow with each byte written and make sure we can still NUL
terminate after.
Tests added to exercise these edge cases.
Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41328
The function ibv_query_device_ex is static inline, it is not exported
from the dso. With lld 16, which is much more picky about versioning and
undefined symbols, this becomes an error.
The ibv_register_driver driver symbol is explicitly versioned in
sources, it is non-existent in un-versioned object files.
Sponsored by: NVidia networking
MFC after: 1 week
The FreeBSD driver support for clang tested explicitly for 32-bit
Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
present to decide whether -m32 should use /usr/lib32. At jrtc27's
suggestion, simply test for a 32-bit platform rather than adding
arm to the list. Upstreamed as
3450272fc2
Bump the freebsd version to force a bootstrap build. This is one
step in adding support for -m32 on arm64.
Reviewed by: jrtc27, brooks, dim
Differential Revision: https://reviews.freebsd.org/D40943
Libarchive 3.7.0
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
MFC after: 2 weeks
PR: 272567 (exp-run)
[builtins][Mips] Un-break FreeBSD build of __clear_cache
Commit 674a17e9bbe8 ("MIPS/compiler_rt: use synci to flush icache on
r6") completely removed the OS-specific guards under the guise of "For
pre-r6, we can use cacheflush libc function, which is same on Linux and
FreeBSD." However, the code in question had guards for Linux and
OpenBSD, not Linux and FreeBSD, and FreeBSD does not have a cacheflush
libc function as claimed, so this was neither the statement they
intended to make nor was it sufficient justification for making the code
completely unconditional. Whilst the upcoming FreeBSD 14 release has
dropped support for MIPS, FreeBSD 13 has support for it.
Fix this by only calling cacheflush on the OSes where it was previously
called, and not on other OSes where it either definitely isn't available
(FreeBSD) or is unknown (any other OS than the three mentioned in this
commit).
This is only needed for MFC'ing, as mips has been removed from
14-CURRENT.
PR: 271047
MFC after: immediately
Intentionally or not, but the libwrap was written in such manner that
if your /etc/hosts.allow doesn't have any domain names, neither smart
keywords like LOCAL or KNOWN, then it will not try to resolve the
client address during the hosts check. This was achieved with the
NOT_INADDR() check that matched IPv4 addresses/prefixes. Extend this
to also skip resolve if client list token looks like IPv6.
Reviewed by: philip, emaste
PR: 269456
Differential revision: https://reviews.freebsd.org/D40070
Important changes (relevant to FreeBSD):
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
Obtained from: libarchive
Libarchive commit: ee45796171324519f0c0bfd012018dd099296336
Libarchive tag: v3.7.0
[PowerPC] Replace PPCISD::VABSD cases with generic ISD::ABDU(X,Y) node
A move towards using the generic ISD::ABDU nodes on more backends
Also support ISD::ABDS for v4i32 types using the existing signbit flip trick
PowerPC has a select(icmp_ugt(x,y),sub(x,y),sub(y,x)) -> abdu(x,y) combine that I intend to move to DAGCombiner in a future patch.
The ABS(SUB(X,Y)) -> PPCISD::VABSD(X,Y,1) v4i32 combine wasn't legal (https://alive2.llvm.org/ce/z/jc2hLU) - so I've removed it, having already added the legal sub nsw tests equivalent.
Differential Revision: https://reviews.llvm.org/D142313
This fixes a "Wasn't expecting to be able to lower this!" fatal error
when compiling graphics/opencv for PowerPC.
Requested by: pkubaj
PR: 271047
MFC after: 1 month
[clang] Reset FP options before template instantiation
AST nodes that may depend on FP options keep them as a difference
relative to the options outside the AST node. At the moment of
instantiation the FP options may be different from the default values,
defined by command-line option. In such case FP attributes would have
unexpected values. For example, the code:
template <class C> void func_01(int last, C) {
func_01(last, int());
}
void func_02() { func_01(0, 1); }
#pragma STDC FENV_ACCESS ON
caused compiler crash, because template instantiation takes place at the
end of translation unit, where pragma STDC FENV_ACCESS is in effect. As
a result, code in the template instantiation would use constrained
intrinsics while the function does not have StrictFP attribute.
To solve this problem, FP attributes in Sema must be set to default
values, defined by command line options.
This change resolves https://github.com/llvm/llvm-project/issues/63542.
Differential Revision: https://reviews.llvm.org/D154359
Requested by: pkubaj
PR: 265755, 265758
MFC after: 1 month
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40923
[Clang] Show type in enum out of range diagnostic
When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:
v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^
This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152788
PR: 271047
MFC after: 1 month
This reapplies upstream commit c0141f3c300f by Aaron Ballman:
Downgrade implicit int and implicit function declaration to warning only
The changes in Clang 15.0.0 which enabled these diagnostics as a
warning which defaulted to an error caused disruption for people
working on distributions such as Gentoo. There was an explicit request
to downgrade these to be warning-only in Clang 15.0.1 with the
expectation that Clang 16 will default the diagnostics to an error.
See
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
for more details on the discussion.
See https://reviews.llvm.org/D133800 for the public review of these
changes.
As noted in the upstream discussion, there are many programs that fail
to configure or build correctly, if these warnings are turned into
errors by default.
Note that most affected programs in ports are relatively old, and are
unlikely to be fixed by actually adjusting their declarations, but by
compiling with -std=gnu89, which downgrades the errors back to warning
again. Lots of tedious work for very little gain.
[clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h
As of https://reviews.llvm.org/D79708, clang-tblgen generates `arm_neon.h`,
`arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
typedef of `bfloat16_t`. However, `arm_neon.h` and `arm_sve.h` include
`arm_bf16.h` immediately before their own typedef:
#include <arm_bf16.h>
typedef __bf16 bfloat16_t;
With a recent version of clang (I used 16.0.1) this results in warnings:
/usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
Since `arm_bf16.h` is very likely supposed to be the one true place where
`bfloat16_t` is defined, I propose to delete the duplicate typedefs from the
generated `arm_neon.h` and `arm_sve.h`.
Reviewed By: sdesmalen, simonbutcher
Differential Revision: https://reviews.llvm.org/D148822
PR: 271047
MFC after: 1 month
[compiler-rt] Include system headers before optionally defining HWCAP macros
In https://reviews.llvm.org/D141285 the optional definitions of `HWCAP`
macros were moved to before their usage. However, they were also moved
to before the inclusion of system headers which can optionally define
them. If any of those system headers then actually defined any of the
`HWCAP` macros, it would result in a redefinition error.
Move the system header includes to just before the optional definitions,
to avoid this problem.
Reviewed By: ilinpv
Differential Revision: https://reviews.llvm.org/D148819
PR: 271047
MFC after: 1 month
