LLVM/project 537e7b5clang/include/clang/DependencyScanning DependencyScannerImpl.h, clang/lib/Tooling DependencyScanningTool.cpp

[clang][DependencyScanning] Fix misplaced Driver includes (NFC) (#187599)

As pointed out in [the review of
#15277](https://github.com/llvm/llvm-project/pull/152770#discussion_r2962823008),
`DependencyScannerImpl.h` includes headers from the driver. However, the
dependency scanning library does not depend on the driver at all. This
PR fixes the include issue.

The dependency on the Driver was removed following the RFC:
https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773
DeltaFile
+0-2clang/include/clang/DependencyScanning/DependencyScannerImpl.h
+2-0clang/lib/Tooling/DependencyScanningTool.cpp
+2-22 files

LLVM/project ec3a719llvm/test/CodeGen/X86 bitreverse.ll

[X86] bitreverse.ll - add additional i128/i256/i512 GFNI test coverage for #187502 (#187552)
DeltaFile
+1,193-0llvm/test/CodeGen/X86/bitreverse.ll
+1,193-01 files

FreeBSD/ports 1f7c58bsysutils/stackit distinfo Makefile

sysutils/stackit: Update 0.55.0 => 0.56.0

Changelog:
https://github.com/stackitcloud/stackit-cli/releases/tag/v0.56.0

PR:     293918
DeltaFile
+5-5sysutils/stackit/distinfo
+1-2sysutils/stackit/Makefile
+6-72 files

FreeNAS/freenas 869b988src/middlewared/middlewared/plugins/container utils.py lifecycle.py, src/middlewared/middlewared/pytest/unit/plugins/container test_hostname.py

NAS-140185 / 26.0.0-BETA.2 / Configure container hostname based on container name (by Qubad786) (#18516)
DeltaFile
+119-0src/middlewared/middlewared/pytest/unit/plugins/container/test_hostname.py
+48-0src/middlewared/middlewared/plugins/container/utils.py
+27-2src/middlewared/middlewared/plugins/container/lifecycle.py
+194-23 files

LLVM/project cbab7e6llvm/lib/Transforms/Utils AMDGPUEmitPrintf.cpp, offload/plugins-nextgen/amdgpu/src rtl.cpp

[AMDGPU] Minor cleanups in offload plugin and AMDGPUEmitPrintf. NFC. (#187587)

Use empty() in assert, brace-init instead of std::make_pair in the
AMDGPU offload plugin, and fix a comment typo in AMDGPUEmitPrintf.
DeltaFile
+2-2offload/plugins-nextgen/amdgpu/src/rtl.cpp
+1-1llvm/lib/Transforms/Utils/AMDGPUEmitPrintf.cpp
+3-32 files

Dreckly/dreckly e3e8f80graphics/ImageMagick distinfo Makefile.common

ImageMagick: Update to 7.1.2.15
DeltaFile
+4-4graphics/ImageMagick/distinfo
+2-2graphics/ImageMagick/Makefile.common
+6-62 files

Dreckly/dreckly 6a9491dtextproc/expat builtin.mk distinfo

expat: Update to 2.7.5
DeltaFile
+11-8textproc/expat/builtin.mk
+4-4textproc/expat/distinfo
+2-2textproc/expat/Makefile
+17-143 files

Dreckly/dreckly 75d9431net/wireshark PLIST options.mk

wireshark: Update to 4.6.4
DeltaFile
+37-36net/wireshark/PLIST
+8-1net/wireshark/options.mk
+4-4net/wireshark/distinfo
+3-3net/wireshark/Makefile
+52-444 files

FreeBSD/ports ae38a4bsysutils/awslim Makefile distinfo, sysutils/awslim/files modules.txt go.sum

sysutils/awslim: Update to 0.6.12

ChangeLog:      https://github.com/fujiwara/awslim/compare/v0.5.0...v0.6.12
Approved by:    hrs (mentor, blanket)
DeltaFile
+894-845sysutils/awslim/files/modules.txt
+860-844sysutils/awslim/files/go.sum
+431-423sysutils/awslim/files/go.mod
+17-6sysutils/awslim/Makefile
+9-9sysutils/awslim/distinfo
+0-18sysutils/awslim/files/patch-all-services.yaml
+2,211-2,1456 files

LLVM/project 61b9fc1clang/test/CodeGenCUDA mangling.cu

[CIR] Upstream CUDA mangling test with LLVM and OGCG verification (#184444)

This PR upstreams the `mangling.cu` test from the ClangIR incubator. 

Building on the feedback from my previous upstreaming PR, I have
expanded the verification for this file to include:
1. **CIR checks:** Verifying the ClangIR generated functions.
2. **LLVM checks:** Verifying the LLVM IR generated via the ClangIR
pipeline.
3. **OGCG checks:** Verifying against the original CodeGen pipeline to
ensure name-mangling parity.

I have also moved the `Inputs/cuda.h` mock header to the upstream
`Inputs` directory to support this and future CUDA tests.

If this multi-stage verification approach looks correct to the
maintainers, I plan to follow up by upstreaming the other currently
passing CUDA test, `simple-nvptx-triple.cu`, using the same standard.

Verified locally with `llvm-lit`. Partially addresses #156747.
DeltaFile
+126-0clang/test/CodeGenCUDA/mangling.cu
+126-01 files

GhostBSD/ports 6220b1bx11/xconfig distinfo Makefile

x11/xconfig: update to 3.3
DeltaFile
+3-3x11/xconfig/distinfo
+1-1x11/xconfig/Makefile
+4-42 files

GhostBSD/xconfig 0e9efdabin xconfig

Merge pull request #54 from ghostbsd/nvidia

Fixed GPU detection logic
DeltaFile
+4-7bin/xconfig
+4-71 files

GhostBSD/xconfig 0c1b497bin xconfig

Fixed GPU detection logic
DeltaFile
+4-7bin/xconfig
+4-71 files

Dreckly/dreckly e0a4c8fgraphics/ImageMagick distinfo Makefile.common

ImageMagick: Update to 7.1.2.15
DeltaFile
+4-4graphics/ImageMagick/distinfo
+2-2graphics/ImageMagick/Makefile.common
+6-62 files

LLVM/project 002d42ellvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/test/Transforms/SLPVectorizer/AArch64 externally-used-copyables.ll revec-reductions.ll

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+157-74llvm/test/Transforms/SLPVectorizer/AArch64/externally-used-copyables.ll
+62-57llvm/test/Transforms/SLPVectorizer/X86/parent-node-non-schedulable.ll
+19-49llvm/test/Transforms/SLPVectorizer/AArch64/revec-reductions.ll
+42-2llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+11-12llvm/test/Transforms/SLPVectorizer/NVPTX/v2f16.ll
+291-1945 files

FreeNAS/freenas ab3fb20tests/sharing_protocols/iscsi test_261_iscsi_cmd.py

Add CI test for PR state preservation across HA failover

Two initiators register keys and one holds a WRITE EXCLUSIVE reservation.
The system is failed over twice (failback included) and after each failover
both keys and the reservation are verified on both paths.
DeltaFile
+152-1tests/sharing_protocols/iscsi/test_261_iscsi_cmd.py
+152-11 files

Dreckly/dreckly 1a48c58textproc/expat builtin.mk distinfo

expat: Update to 2.7.5
DeltaFile
+11-8textproc/expat/builtin.mk
+4-4textproc/expat/distinfo
+2-2textproc/expat/Makefile
+17-143 files

Dreckly/dreckly 1c9bb40www/curl options.mk Makefile

curl: Update to 8.19.0
DeltaFile
+14-11www/curl/options.mk
+7-2www/curl/Makefile
+4-4www/curl/distinfo
+5-2www/curl/buildlink3.mk
+5-1www/curl/PLIST
+3-2www/curl/Makefile.common
+38-226 files

NetBSD/src j6EN9Lysys/dev/ic aic7xxx_inline.h

   ahc: Fix support for multi-channel PCI controllers.

   Some old EISA controllers driven by ahc had two channels on one
   controller (aka "TWIN" channels), while all later PCI models
   supporting multiple channels did so by having multiple controllers
   in one PCI device, each being a separate PCI function.

   The ahc interrupt handler wrongly assumed that anything but channel
   'A' is always the 2nd channel of a TWIN channel controller, passing
   sc_channel_b to scsipi_channel_{freeze,thaw}(). This of course is
   wrong for multi-channel PCI ahc controllers, leading to a immediate
   panic when there's anything connected to any channel but 'A'.
VersionDeltaFile
1.16+8-3sys/dev/ic/aic7xxx_inline.h
+8-31 files

FreeBSD/ports 4690b8ceditors/vim distinfo Makefile

editors/vim: Update to 9.2.0204 (security fix)

In particular, this addresses the following:
  Problem:  The glob() function on Unix-like systems does not escape
            newline characters when expanding wildcards. A maliciously
            crafted string containing '\n' can be used as a command
            separator to execute arbitrary shell commands via
            mch_expand_wildcards(). This depends on the user's 'shell'
            setting.
  Solution: Add the newline character ('\n') to the SHELL_SPECIAL
            definition to ensure it is properly escaped before being
            passed to the shell (pyllyukko).

Security:       GHSA-w5jw-f54h-x46c
(cherry picked from commit a215214dc5d94d8906ebddd92640062e91b0fd7b)
DeltaFile
+3-3editors/vim/distinfo
+1-1editors/vim/Makefile
+4-42 files

FreeBSD/ports a215214editors/vim distinfo Makefile

editors/vim: Update to 9.2.0204 (security fix)

In particular, this addresses the following:
  Problem:  The glob() function on Unix-like systems does not escape
            newline characters when expanding wildcards. A maliciously
            crafted string containing '\n' can be used as a command
            separator to execute arbitrary shell commands via
            mch_expand_wildcards(). This depends on the user's 'shell'
            setting.
  Solution: Add the newline character ('\n') to the SHELL_SPECIAL
            definition to ensure it is properly escaped before being
            passed to the shell (pyllyukko).

Security:       GHSA-w5jw-f54h-x46c
DeltaFile
+3-3editors/vim/distinfo
+1-1editors/vim/Makefile
+4-42 files

LLVM/project 9cb1e37clang/lib/Driver/ToolChains AMDGPU.cpp HIPAMD.cpp

[Clang][AMDGPU] Minor driver cleanups. NFC. (#187586)

Use empty() instead of size() checks, back() instead of [size()-1], and
brace-init instead of std::make_pair in the AMDGPU and HIP driver
toolchains.
DeltaFile
+3-4clang/lib/Driver/ToolChains/AMDGPU.cpp
+1-2clang/lib/Driver/ToolChains/HIPAMD.cpp
+4-62 files

LLVM/project 7efcd61libc/docs/dev modular_format.rst, libc/src/stdio sprintf_modular.cpp snprintf_modular.cpp

[libc] Modular printf option (float only) (#147426)

This adds LIBC_CONF_PRINTF_MODULAR, which causes floating point support
(later, others) to be weakly linked into the implementation.
__printf_modular becomes the main entry point of the implementaiton, an
printf itself wraps __printf_modular. printf it also contains a
BFD_RELOC_NONE relocation to bring in the float aspect.

See issue #146159 for context.
DeltaFile
+68-0libc/docs/dev/modular_format.rst
+54-0libc/src/stdio/sprintf_modular.cpp
+54-0libc/src/stdio/snprintf_modular.cpp
+51-0libc/src/stdio/vsnprintf_modular.cpp
+50-0libc/src/stdio/vsprintf_modular.cpp
+43-0libc/src/stdio/asprintf_modular.cpp
+320-046 files not shown
+735-2752 files

Illumos/gate 995b170usr/src/boot Makefile.version, usr/src/boot/efi/loader/arch/amd64 trap.c

17887 loader.efi: panic() should show stack trace
Reviewed by: Jason King <jason.brian.king+illumos at gmail.com>
Approved by: Dan McDonald <danmcd at edgecast.io>
DeltaFile
+59-29usr/src/boot/efi/loader/arch/amd64/trap.c
+1-1usr/src/boot/Makefile.version
+60-302 files

LLVM/project 4e19eeellvm/include/llvm/CodeGen MachineInstr.h, llvm/lib/Target/AMDGPU SIInstrInfo.h

[NFC] Annotate CommentFlag with underlying type (#186560)

This is stored in `uint8_t AsmPrinterFlags`, and `setAsmPrinterFlag` was
already using `uint8_t` in the API. This change doesn't use a scoped
enum as targets extend this enum by starting their enums with the
`TAsmComments` value.

This also introduces a typedef for the uint8_t for documentation purposes.
DeltaFile
+13-12llvm/include/llvm/CodeGen/MachineInstr.h
+1-1llvm/lib/Target/X86/X86InstrInfo.h
+1-1llvm/lib/Target/AMDGPU/SIInstrInfo.h
+1-1llvm/lib/Target/SPIRV/SPIRVInstrInfo.h
+16-154 files

LLVM/project e895a80lldb/include/lldb/Symbol CompilerType.h TypeSystem.h, lldb/source/Plugins/TypeSystem/Clang TypeSystemClang.cpp TypeSystemClang.h

[lldb][TypeSystem] Add CompilerType::IsMemberDataPointerType (#187172)

**Description:**

Adds `IsMemberDataPointerType()` to CompilerType / TypeSystem /
TypeSystemClang, mirroring the existing `IsMemberFunctionPointerType()`.

LLDB already has `IsMemberFunctionPointerType()` to identify member
function pointers but no counterpart for member data pointers. The only
way to check for member data pointers was the indirect `GetTypeClass()
== eTypeClassMemberPointer && !IsMemberFunctionPointerType()`, which is
awkward.

This pr is split out from a larger [fix,
186629](https://github.com/llvm/llvm-project/pull/186629) for LLDB
mishandling non-type template parameters (NTTPs) of pointer-to-member
types, where cleanly distinguishing member data pointers from member
function pointers is needed. The new API delegates to clang's
`QualType::isMemberDataPointerType()` via the same I`sTypeImpl` pattern

    [12 lines not shown]
DeltaFile
+29-0lldb/unittests/Symbol/TestTypeSystemClang.cpp
+9-0lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+7-0lldb/source/Symbol/CompilerType.cpp
+2-0lldb/include/lldb/Symbol/CompilerType.h
+2-0lldb/include/lldb/Symbol/TypeSystem.h
+2-0lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+51-06 files

LLVM/project 178f4e6llvm/lib/Target/AMDGPU AMDGPULowerVGPREncoding.cpp, llvm/test/CodeGen/AMDGPU vgpr-setreg-mode-swar.mir hazard-setreg-vgpr-msb-gfx1250.mir

[AMDGPU] Fix setreg handling in the VGPR MSB lowering

There are multiple issues with it:

1. It can skip inserting S_SET_VGPR_MSB if we set the mode via
   piggybacking. We are now relying on the HW bug for correct
   behavior. If/when the bug is fixed lowering will be incorrect.
2. We should just unconditionally update MSBs if immediate allows it.
   We shall set correct bits and keep the rest of the immediate
   (that is done). There is no reasonable way for an user to change
   MSBs nor does it do anything good to set it with SETREG and then
   immediately overwrite with S_SET_VGPR_MSB.
3. We can always update immediate if Offset is zero.
4. Redundant mode changes created as seen in the
   hazard-setreg-vgpr-msb-gfx1250.mir.
5. Decoding of the immediate was also wrong with non-zero offset
   and did not factor MSB fixup offset handling.

With unconditional immediate update most of time and not relying on

    [12 lines not shown]
DeltaFile
+86-33llvm/test/CodeGen/AMDGPU/vgpr-setreg-mode-swar.mir
+30-38llvm/lib/Target/AMDGPU/AMDGPULowerVGPREncoding.cpp
+12-18llvm/test/CodeGen/AMDGPU/hazard-setreg-vgpr-msb-gfx1250.mir
+128-893 files

LLVM/project 59bc629llvm/lib/Target/AMDGPU/Utils AMDGPUBaseInfo.cpp, llvm/test/CodeGen/AMDGPU vgpr-setreg-mode-swar.mir

[AMDGPU] Fix decoding of SETREG MSBs (#187578)

Decoding of the immediate was wrong with non-zero offset
and did not factor MSB fixup offset handling.
DeltaFile
+40-0llvm/test/CodeGen/AMDGPU/vgpr-setreg-mode-swar.mir
+5-2llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
+45-22 files

LLVM/project 33cfe28llvm/lib/Target/DirectX DXILShaderFlags.cpp, llvm/test/CodeGen/DirectX/ShaderFlags typed-srv-load.ll

[DirectX] Fix TypedBuffer load shader flag mismatch (#187393)

Fixes #187225.

The `TypedUAVLoadAdditionalFormats` shader flag was being set for all
TypedBuffer vector loads, so loading from a `Buffer<int64_t2>` was
incorrectly triggering this flag and causing the mismatch. This PR
changes it so the flag is only set for UAV loads.
DeltaFile
+43-0llvm/test/CodeGen/DirectX/ShaderFlags/typed-srv-load.ll
+1-1llvm/lib/Target/DirectX/DXILShaderFlags.cpp
+44-12 files

FreeBSD/ports 56d7761games/flightgear Makefile

games/flightgear: prevent to pickup qt6 if it co-exist with qt5 (+)

Reported by:    bulk -t
Approved by:    portmgr blanket
DeltaFile
+1-1games/flightgear/Makefile
+1-11 files