make ttm_device_prepare_hibernation() return early
kettenis reports the ttm_tm_swapout() change is not enough to fix
hibernate with amdgpu when X is running.
The call to ttm_device_prepare_hibernation()/ttm_tm_swapout() in the
hibernate path was added in a linux commit from 2025:
924dda024f3bea64be5f3ac067a075e466739dc9
drm/amdgpu: move GTT to shmem after eviction for hibernation
The linux reason for doing this (server cards with lots of VRAM) isn't
something that concerns us.
ok kettenis@
When pledged, the special access(2) inspection for "/etc/localtime" has not
been needed since changes made in lib/libc/time/localtime.c 1.58 (2019)
pointed out by david leadbeater
[clang] DeducedTypes deduction kind fix and improvement
This is a small refactor of how DeducedType and it's derived types are
represented.
The different deduction kinds are spelled out in an enum, and how this
is tracked is simplified, to allow easier profiling.
How these types are constructed and canonicalized is also brought more
in line with how it works for the other types.
This fixes a crash reported here: https://github.com/llvm/llvm-project/issues/167513#issuecomment-3692962115
[clang] DeducedTypes deduction kind fix and improvement
This is a small refactor of how DeducedType and it's derived types are
represented.
The different deduction kinds are spelled out in an enum, and how this
is tracked is simplified, to allow easier profiling.
How these types are constructed and canonicalized is also brought more
in line with how it works for the other types.
This fixes a crash reported here: https://github.com/llvm/llvm-project/issues/167513#issuecomment-3692962115
[clang] Skip dllexport of inherited constructors with unsatisfied constraints (#186497)
When a class is marked `__declspec(dllexport)`, Clang eagerly creates
inherited constructors via `findInheritingConstructor` and propagates
the dllexport attribute to all members. This bypasses overload
resolution, which would normally filter out constructors whose requires
clause is not satisfied. As a result, Clang attempted to instantiate
constructor bodies that should never be available, causing spurious
compilation errors.
Add constraint satisfaction checks in `checkClassLevelDLLAttribute` to
match MSVC behavior:
1. Before eagerly creating inherited constructors, verify that the base
constructor's `requires` clause is satisfied. Skip creation otherwise.
2. Before applying dllexport to non-inherited methods of class template
specializations, verify constraint satisfaction. This handles the case
where `dllexport` propagates to a base template specialization whose own
[9 lines not shown]
[clang] DeducedTypes deduction kind fix and improvement
This is a small refactor of how DeducedType and it's derived types are
represented.
The different deduction kinds are spelled out in an enum, and how this
is tracked is simplified, to allow easier profiling.
How these types are constructed and canonicalized is also brought more
in line with how it works for the other types.
This fixes a crash reported here: https://github.com/llvm/llvm-project/issues/167513#issuecomment-3692962115
[lld][ELF] Fix crash when relaxation pass encounters synthetic sections
In LoongArch and RISC-V, the relaxation pass iterates over input sections
within executable output sections. When a linker script places a synthetic
section (e.g., .got) into such an output section, the linker would crash
because synthetic sections do not have the relaxAux field initialized.
The relaxAux data structure is only allocated for non-synthetic sections
in initSymbolAnchors. This patch adds the necessary null checks in the
relaxation loops (relaxOnce and finalizeRelax) to skip sections that
do not require relaxation.
A null check is also added to elf::initSymbolAnchors to ensure the
subsequent sorting of anchors is safe.
Fixes: #184757
Reviewers: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/184758
[LoongArch] Remove unreachable Value check in fixupLeb128 (#186297)
Value is guaranteed to be zero after the loop:
for (I = 0; Value; ++I, Value >>= 7)
Therefore the subsequent `if (Value)` condition is always false.
Remove the unreachable code. Reported by PVS-Studio.
Fixed: #170122
