[mlir][LLVM] Fix crash combining nested pointer data layouts (#222855)
While investigating #222356, an LLVM pointer data layout compatibility
crash was found when combining nested layouts.
`LLVMPointerType::areCompatible()` passed the `DataLayoutEntryInterface`
itself to `extractPointerSpecValue()`, even though that helper expects
the entry value as a `DenseIntElementsAttr`.
Use `getValue()` for the enclosing pointer entry, matching the handling
of the nested entry and allowing compatible pointer layouts to be
combined without asserting.
The separate builtin data layout combination issue found during the same
investigation is handled independently.
Related to #222356.
AI-assisted tooling was used during development and validation.
math/kissfft: Add new ports: Mixed-radix Fast Fourier Transform
There are many great fft libraries already around. Kiss FFT is not trying to
be better than any of them. It only attempts to be a reasonably efficient,
moderately useful FFT that can use fixed or floating data types and can be
incorporated into someone's C program in a few minutes with trivial licensing.
WWW: https://github.com/mborgerding/kissfft/
x11-themes/sddm-freebsd-black-theme: Update to 1.4 for Qt6
- Switch to new upstream
- Pass maintainership to submitter
PR: 293449
Submitted by: Xiaodi Ma
[SelectionDAG] Improve operand promotion for concat vectors. (#234070)
Create a new concat of legal type and then truncate it to the correct
size instead of creating a build vector.
[lldb] Create COFFObjectFile directly in ObjectFilePECOFF (#229797)
`ObjectFilePECOFF` calls `llvm::object::createBinary` and then requires
the result to be a `COFFObjectFile`. `createBinary` dispatches to every
object file format, so it links all of them into lldb-server.
`MagicBytesMatch` has already established that the file is PE/COFF, so
call `COFFObjectFile::create`.
[C++20][Modules] Omit imported PCM file info for explicitly mapped header units (#235597)
C++20 named module dependencies are already serialized without PCM file
information. This PR applies the same behavior to header units loaded through
a named mapping (`-fmodule-file=<name>=<pcm>`). Header units loaded
through `-fmodule-file=<file>` retain their file information.
An explicit `IsCXX20ModuleOrPrebuiltHeaderUnit` field is added to
the `IMPORT` record rather than reusing `StandardCXXModule`, which
also controls imported-module lookup.
This also adds a missing test for the existing named-module behavior and
tests the corresponding header-unit behavior introduced by this change.
[TableGen] Use "parent class" terminology in TGParser. NFC. (#235106)
TGParser called the classes and multiclasses that a record or multiclass
inherits from "subclasses", for example in AddSubClass and
SubClassReference, although they are its parent classes. Rename them to
match the terminology of the TableGen grammar in ProgRef, e.g.
AddParentClass and ClassReference, and update the comments
accordingly, including the grammar comments.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
Merge tag 'backlight-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
Pull backlight updates from Lee Jones:
"Improvements & Fixes:
- Qualcomm WLED: Fix a NULL pointer dereference in `wled_remove()` by
setting platform driver data in `wled_probe()`
- Qualcomm WLED: Fix the WLED3 brightness register stride to prevent
consecutive string writes from overlapping
- Qualcomm WLED: Read back the hardware-programmed brightness at
probe, expose it via
`get_brightness()`, and prevent unbalanced OVP IRQ enabling
- TI LM3630A: Cancel delayed work synchronously after freeing the IRQ
and before destroying the workqueue in `lm3630a_remove()`
Cleanups & Refactoring:
- Ilitek ILI9320 / Kinetic KTD253: Fix spelling typos in comments"
* tag 'backlight-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
backlight: qcom-wled: Read back the programmed brightness at probe
[5 lines not shown]
[AMDGPU] Fold high-half extracts into op_sel for i16 mad (#231410)
Use the VOP3OpSel complex pattern for the sources of the i16 mul+add
patterns that select the op_sel-capable v_mad_u16 on GFX10+, so that a
source taken from the high half of a packed register is read with op_sel
instead of being extracted with a shift first.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
[DebugInfo] Salvage replaced sdiv instructions (#234602)
When `correlated-propagation` removed SDiv instructions, it doesn't
correctly salvage the debug information. This leads to variables in the
debugger having incorrect values. This patch makes sure we salvage the
debug information correctly.
(See https://github.com/llvm/llvm-project/issues/218630, which this
fixes)
sctp: improve handling of SO_SETFIB socket option
Since SCTP keeps fibnum in the SCTP protocol control block,
the code can't just defer the processing to the IPv4 or IPv6
layer. Therefore it needs to be implemented in the the SCTP
layer and it needs to call the socket layer function.
PR: 300091
Reviewed by: tuexen
Fixes: caccbaef8e26 ("socket: Move SO_SETFIB handling to protocol layers")
MFC after: 3 days
MFC to: stable/14
MFC to: stable/15
[AMDGPU] Fix sc1 encoding of gfx940 fp atomics with AGPR results
The *_F64 FLAT and GLOBAL atomics have separate VI and GFX940 reals,
because the VI reals are defined with has_sccb=0 and so do not encode
bit 25, which is SC1 on GFX940. However:
- #129668 removed the isGFX90AOnly predicate from the VI reals, so on
GFX940+ both the VI and GFX940 reals matched in the assembler. The
GFX940 ones happened to win because they were defined later.
- The GFX940 multiclasses did not define *_RTN_agpr reals, so the AGPR
forms of the returning atomics always used the VI reals on GFX940+.
The assembler silently dropped sc1 for these, the disassembler could
not decode them with sc1 set, and codegen dropped sc1 from the
*_RTN_agpr pseudos.
Fix this by adding *_RTN_agpr (and *_SADDR_RTN_agpr) reals to the GFX940
atomic multiclasses, and restricting the VI f64 reals to
isGFX8GFX9NotGFX940, like the neighbouring f32 and pk_f16 ones.
[6 lines not shown]
[AMDGPU] Precommit tests for gfx942 fp atomics with AGPR results (#232059)
Add MC, disassembler and codegen tests for FLAT and GLOBAL fp atomics on
gfx942 and gfx950, with more complete coverage of the f64 atomics on
gfx90a and gfx942.
The returning forms of {flat,global}_atomic_{add,min,max}_f64 with AGPR
operands currently use the *_RTN_agpr_vi reals on gfx942, which do not
encode bit 25 (SC1), so:
- the assembler silently drops sc1
- the disassembler fails to decode them with sc1 set
- the *_RTN_agpr pseudos are lowered without sc1
Similarly for global_atomic_add_f32 and global_atomic_pk_add_f16, where
codegen drops sc1 from the *_RTN_agpr pseudos, and the assembler and
disassembler reject the AGPR returning forms altogether.
The codegen test is written in MIR because nothing currently selects the
[13 lines not shown]
[lldb-dap][docs] Note the version that introduced an extension (#235773)
Record the LLDB release each lldb-dap extension first shipped in.
To avoid user creating issue of missing fields. similar to
https://github.com/llvm/llvm-project/issues/161998
Merge tag 'leds-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Support & Features:
- Core: Add `led_trigger_notify_hw_control_changed()` to allow
drivers to notify the core of autonomous hardware control
transitions
- Core: Add the `hw_offloaded()` trigger callback and
`trigger_may_offload_to_hw` sysfs attribute to expose
hardware-offloaded triggers
- Netdev Trigger: Implement the `hw_offloaded()` callback to report
hardware control state to the LED core
- Analog Devices LTC3208: Add support for the LTC3208 7-channel
multi-display I2C LED driver
- ChromeOS EC: Implement the `hw_offloaded()` callback for the
`chromeos-auto` trigger
- CZ.NIC Turris Omnia: Implement the `hw_offloaded()` callback and
declare `omnia-mcu` as a hardware control trigger
- STMicroelectronics ST1202: Add hardware-accelerated blink support
[101 lines not shown]
*/*: Bump consumers after graphics/ImageMagick{6,7} update
ImageInfo and DrawInfo gained a member, GetImageInfo() and
GetDrawInfo() clear the new size on a caller-provided struct.
PR: 300074
With hat: ports-secteam
Sponsored by: Netzkommune GmbH
(cherry picked from commit ed4c5e5da5d94699da0740485ffce262bdae6dae)
[offload][omp] Remove data_fence
All supported backends execute enqueued work on a given queue in
submission order (CUDA, AMDGPU, and Host queues are always in-order;
Level Zero's default and non-default in-order/synchronous command
modes are as well), so the explicit data-fence used to order a
pointer-attachment after prior data transfers is unnecessary. Remove
the DeviceTy/GenericDeviceTy/GenericPluginTy dataFence chain and the
now-unused olQueueBarrier liboffload API added to support it.
[LLDB] Use `-fastproxy` when building swig bridge without limited python API (#234206)
Per [swig
docs](https://www.swig.org/Doc4.4/Python.html#Python_fastproxy).
Additionally, the `-olddefs` option is included so that the doc comments
still function. The latter change makes importing the LLDB module a bit
slower, but makes every method call a good bit faster.
Co-authored-by: Jonas Devlieghere <jonas at devlieghere.com>
