cad/ngspice_rework: fix build with libc++ 21
With libc++ 21 cad/ngspice_rework fails to build, with errors similar to:
In file included from hicumL2temp.cpp:11:
../../../../src/include/cppduals/duals/dual:444:8: error: 'is_compound' cannot be specialized: Users are not allowed to specialize this standard library entity [-Winvalid-specialization]
444 | struct is_compound<duals::dual<T>> : true_type {};
| ^
/usr/include/c++/v1/__type_traits/is_compound.h:25:8: note: marked '_Clang::no_specializations' here
25 | struct _LIBCPP_NO_SPECIALIZATIONS is_compound : _BoolConstant<__is_compound(_Tp)> {};
| ^
/usr/include/c++/v1/__config:1167:9: note: expanded from macro '_LIBCPP_NO_SPECIALIZATIONS'
1167 | [[_Clang::__no_specializations__("Users are not allowed to specialize this standard library entity")]]
| ^
This is because libc++ 21 no longer allows specializing a number of
standard library entities. Delete out the specialization to make the
build complete.
[5 lines not shown]
cad/ngspice_rework: fix build with libc++ 21
With libc++ 21 cad/ngspice_rework fails to build, with errors similar to:
In file included from hicumL2temp.cpp:11:
../../../../src/include/cppduals/duals/dual:444:8: error: 'is_compound' cannot be specialized: Users are not allowed to specialize this standard library entity [-Winvalid-specialization]
444 | struct is_compound<duals::dual<T>> : true_type {};
| ^
/usr/include/c++/v1/__type_traits/is_compound.h:25:8: note: marked '_Clang::no_specializations' here
25 | struct _LIBCPP_NO_SPECIALIZATIONS is_compound : _BoolConstant<__is_compound(_Tp)> {};
| ^
/usr/include/c++/v1/__config:1167:9: note: expanded from macro '_LIBCPP_NO_SPECIALIZATIONS'
1167 | [[_Clang::__no_specializations__("Users are not allowed to specialize this standard library entity")]]
| ^
This is because libc++ 21 no longer allows specializing a number of
standard library entities. Delete out the specialization to make the
build complete.
[3 lines not shown]
zpl_super: prefer "new" mount API when available
This API has been available since kernel 5.2, and having it available
(almost) everywhere should give us a lot more flexibility for mount
management in the future.
Sponsored-by: TrueNAS
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18260
system(3): Fix null case
Our manual page states that if given a null pointer, system() returns
non-zero if the shell is available and zero if it is not. This is
consistent with the C standard's description of system(), but it is not
what we actually do. What we actually do is always return non-zero, as
required by POSIX.
As the POSIX rationale explains, implementing the logic required by the
C standard does not violate POSIX, since a conforming system always has
a shell, therefore the logic will always return non-zero.
Since our libc is commonly used in non-conforming situations such as
chroots or thin jails, we should implement the full logic required by
the C standard.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: obiwac, bnovkov, kevans
Differential Revision: https://reviews.freebsd.org/D55484
system(3): Clarify return values
Our manual page currently states that system() will return 127 if it
fails to execute the shell. The actual return value is, to quote POSIX,
“as if the command language interpreter had terminated using exit(127)
or _exit(127)”.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: bnovkov, kevans
Differential Revision: https://reviews.freebsd.org/D55483
system(3): Improve signal handling
Ignore SIGINT and SIGQUIT and block SIGCHLD, as POSIX requires.
To deal with the concurrency problem described in POSIX, we keep track
of the count of concurrent invocations. We ignore and block signals
only when the counter was zero before we incremented it, and restore
them only when the counter reaches zero after we decrement it.
Note that this does not address the issue of thread cancellation.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: bnovkov, sef, kevans
Differential Revision: https://reviews.freebsd.org/D55471
[AMDGPU] Implement -amdgpu-spill-cfi-saved-regs
These spills need special CFI anyway, so implementing them directly
where CFI is emitted avoids the need to invent a mechanism to track them
from ISel.
Change-Id: If4f34abb3a8e0e46b859a7c74ade21eff58c4047
Co-authored-by: Scott Linder scott.linder at amd.com
Co-authored-by: Venkata Ramanaiah Nalamothu VenkataRamanaiah.Nalamothu at amd.com
[AMDGPU] Make slow VOPD assert under EXPENSIVE_CHECKS (#183166)
The assert is algorithmically slow. To preserve the usability of release_assert
builds, move it under EXPENSIVE_CHECKS. On some workloads it increased compile
time by 40-50x.
net/freerdp: Update 2.11.7 => 2.11.8, deprecate
"
This release will be the last official one for the 2.x series of FreeRDP.
From this point on we will no longer maintain this branch and urge all to
upgrade to FreeRDP 3.x.
"
Set EXPIRATION_DATE to 2026-12-31.
Changelog:
https://github.com/FreeRDP/FreeRDP/releases/tag/2.11.8
MFH: 2026Q1
(cherry picked from commit f12119901a1128f812f36cee29fd32c0f5174e64)
[libc][math] Refactor fdim family to header-only (#182190)
Refactors the fdim math family to be header-only.
Closes https://github.com/llvm/llvm-project/issues/182188
Target Functions:
- fdim
- fdimbf16
- fdimf
- fdimf128
- fdimf16
- fdiml
[win] Control Flow Guard: Add support for the MSVC /d2guardnochecks command (#182967)
This adds support for MSVC's `/d2guardnochecks` undocumented flag. This
flag is similar to `-guard:cf,nochecks` and `-cfguard-no-checks` in that
it instructs the compiler to emit the metadata for Control Flow Guard
WITHOUT emitting checks (aka: "table only" mode), but it differs from
those existing flags because if only takes effect if another flag is
used to enable Control Flow Guard (i.e., `/d2guardnochecks` by itself
does nothing, `/d2guardnochecks /guard:cf` enables table-only mode for
Control Flow Guard).
[clang][modules-driver] Generate jobs from Standard library module manifest entries (#182182)
This patch is part of a series to support driver-managed module builds.
To support imports of the Standard library modules (std and
std.compat), the driver must generate frontend jobs for each module
before performing the dependency scan.
The source paths for these modules, along with additional information
required to precompile them, are provided by the Standard library
modules manifest.
This change implements the parsing and handling of the manifest in the
modules-driver.
This change is part of an effort to split #152770 into smaller, more
manageable pieces.
RFC for driver-managed module builds:
https://discourse.llvm.org/t/rfc-modules-support-simple-c-20-modules-use-from-the-clang-driver-without-a-build-system
net/freerdp: Update 2.11.7 => 2.11.8, deprecate
"
This release will be the last official one for the 2.x series of FreeRDP.
From this point on we will no longer maintain this branch and urge all to
upgrade to FreeRDP 3.x.
"
Set EXPIRATION_DATE to 2026-12-31.
Changelog:
https://github.com/FreeRDP/FreeRDP/releases/tag/2.11.8
MFH: 2026Q1
[NFC][VPlan] Add initial tests for future VPlan-based stride MV
I tried to include both the features that current
LoopAccessAnalysis-based transformation supports (e.g., trunc/sext of
stride) but also cases where the current implementation behaves poorly,
e.g., https://godbolt.org/z/h31c3zKxK; as well as some other potentially
interesting scenarios I could imagine.
The are two test files with the same content. One is for VPlan dump change of
the future transformation alone (I'll update `-vplan-print-after` in the next
PR), another is for the full vectorizer pipeline. The latter have two `RUN:`
lines:
* No multiversioning, so the next PR diff can show the transformation itself
* Stride multiversionin performed in LAA, so that we can compare future
VPlan-based transformation vs old behavior.
icp: add SHA512 implementation using Intel SHA512 extensions
Generated from crypto/sha/asm/sha512-x86_64.pl in
openssl/openssl at 241d4826f8.
Sponsored-by: TrueNAS
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Attila Fülöp <attila at fueloep.org>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18233
simd: detect and surface support for Intel SHA512 extensions
Recent Intel CPUs (starting with Arrow Lake and Lunar Lake) include new
vectorised SHA512 instructions. Detect them and make them available to
the rest of the system.
Note the internal name "sha512ext". This is to disambiguate from other
uses of "sha512".
Sponsored-by: TrueNAS
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Attila Fülöp <attila at fueloep.org>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18233
Revert "[lldb] Batch breakpoint step-over for threads stopped at the … (#183378)
…same site (re-land) (#182944)"
This reverts commit 94d9f1b3cbb02700d9cd3339c1dbf44c0d13b550.
www/caddy: Remove NTML plugin as it causes issues with service control that can not worked around with anymore.
The NTML plugin and caddy core diverged too much and its considered unmaintained. While there clean up all service control workarounds that were implemented.
Since removing the service control (caddy_control.py) script would make it hard to somehow funnel caddyfile validation in, this has been removed too.
Our input is heavily validated so the Caddyfile will be valid in almost all cases, and in cases its not the log will show the error.
[mlir][xegpu] Add vector layout conflict handling in XeGPU layout propagation pass. (#182402)
This PR adds support for layout conflict handling for vector operands. A
conflict for a vector operand occurs when a value consumed at a given
operand is not in the expected layout in the context of the consumer
(for example `vector.multi_reduction` op's source require a specific
layout inferred from its current result layout). To resolve this
conflict, we insert an `xegpu.convert_layout` right after the producer
(essentially duplicating the producer with expected layout) and use the
new value in the consumer.
