FreeBSD/ports 8547b5cnet/asterisk22 distinfo Makefile, net/asterisk22/files patch-build__tools_make__xml__documentation

net/asterisk22: Update 22.9.0 => 22.10.1

Changelogs:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-22.10.0.html
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-22.10.1.html

PR:             296326
Approved by:    Oleksandr Kryvulia <o.kryvulia at flex-it.com.ua> (maintainer)
Security:       GHSA-3g56-cgrh-95p5
Security:       GHSA-3rhj-hhw7-m6fw
Security:       GHSA-4pgv-j3mr-3rcp
Security:       GHSA-589g-qgf8-m6mx
Security:       GHSA-746q-794h-cc7f
Security:       GHSA-8jhw-m2hg-vp3h
Security:       GHSA-8jw3-ccr9-xrmf
Security:       GHSA-g8q2-p36q-94f6
Security:       GHSA-h5hv-jmgj-92q2 CVE-2022-37325
Security:       GHSA-j2mm-57pq-jh94
Security:       GHSA-mxgm-8c6f-5p8f

    [14 lines not shown]
DeltaFile
+14-14net/asterisk22/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk22/distinfo
+2-2net/asterisk22/Makefile
+1-0net/asterisk22/pkg-plist
+22-214 files

FreeBSD/ports 2a9884enet/asterisk22 distinfo Makefile, net/asterisk22/files patch-build__tools_make__xml__documentation

net/asterisk22: Update 22.8.2 → 22.9.0

Changelog:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-22.9.0.html

PR:             294412
Sponsored by:   FLEX-IT LLC
Sponsored by:   UNIS Labs

(cherry picked from commit 78346040cff80bc386bbcdc0cbb7dc61414c1c12)
DeltaFile
+39-5net/asterisk22/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk22/distinfo
+2-3net/asterisk22/Makefile
+1-0net/asterisk22/pkg-plist
+47-134 files

FreeBSD/ports abd04c0net/asterisk20 distinfo Makefile, net/asterisk20/files patch-build__tools_make__xml__documentation

net/asterisk20: Update 20.19.0 => 20.20.1

Changelogs:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.20.0.html
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.20.1.html

PR:             296366
Security:       GHSA-3g56-cgrh-95p5
Security:       GHSA-3rhj-hhw7-m6fw
Security:       GHSA-4pgv-j3mr-3rcp
Security:       GHSA-589g-qgf8-m6mx
Security:       GHSA-746q-794h-cc7f
Security:       GHSA-8jhw-m2hg-vp3h
Security:       GHSA-8jw3-ccr9-xrmf
Security:       GHSA-g8q2-p36q-94f6
Security:       GHSA-j2mm-57pq-jh94
Security:       GHSA-mxgm-8c6f-5p8f
Security:       GHSA-ph27-3m5q-mj5m
Security:       GHSA-q9fr-m7g8-6ph5

    [12 lines not shown]
DeltaFile
+14-14net/asterisk20/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk20/distinfo
+2-2net/asterisk20/Makefile
+1-0net/asterisk20/pkg-plist
+22-214 files

FreeBSD/ports 2b7accdnet/asterisk20 distinfo Makefile, net/asterisk20/files patch-build__tools_make__xml__documentation

net/asterisk20: Update 20.18.2 → 20.19.0

Changelog:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.19.0.html

PR:             294411
Sponsored by:   FLEX-IT LLC
Sponsored by:   UNIS Labs

(cherry picked from commit a02bd2eb52acae96f4e13ff07d5974eb61db1252)
DeltaFile
+39-5net/asterisk20/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk20/distinfo
+2-3net/asterisk20/Makefile
+1-0net/asterisk20/pkg-plist
+47-134 files

FreeBSD/ports 92c35ebnet/asterisk22 distinfo Makefile, net/asterisk22/files patch-build__tools_make__xml__documentation

net/asterisk22: Update 22.9.0 => 22.10.1

Changelogs:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-22.10.0.html
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-22.10.1.html

PR:             296326
Approved by:    Oleksandr Kryvulia <o.kryvulia at flex-it.com.ua> (maintainer)
Security:       GHSA-3g56-cgrh-95p5
Security:       GHSA-3rhj-hhw7-m6fw
Security:       GHSA-4pgv-j3mr-3rcp
Security:       GHSA-589g-qgf8-m6mx
Security:       GHSA-746q-794h-cc7f
Security:       GHSA-8jhw-m2hg-vp3h
Security:       GHSA-8jw3-ccr9-xrmf
Security:       GHSA-g8q2-p36q-94f6
Security:       GHSA-h5hv-jmgj-92q2 CVE-2022-37325
Security:       GHSA-j2mm-57pq-jh94
Security:       GHSA-mxgm-8c6f-5p8f

    [12 lines not shown]
DeltaFile
+14-14net/asterisk22/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk22/distinfo
+2-2net/asterisk22/Makefile
+1-0net/asterisk22/pkg-plist
+22-214 files

FreeBSD/ports b61744bnet/asterisk20 distinfo Makefile, net/asterisk20/files patch-build__tools_make__xml__documentation

net/asterisk20: Update 20.19.0 => 20.20.1

Changelogs:
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.20.0.html
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.20.1.html

PR:             296366
Security:       GHSA-3g56-cgrh-95p5
Security:       GHSA-3rhj-hhw7-m6fw
Security:       GHSA-4pgv-j3mr-3rcp
Security:       GHSA-589g-qgf8-m6mx
Security:       GHSA-746q-794h-cc7f
Security:       GHSA-8jhw-m2hg-vp3h
Security:       GHSA-8jw3-ccr9-xrmf
Security:       GHSA-g8q2-p36q-94f6
Security:       GHSA-j2mm-57pq-jh94
Security:       GHSA-mxgm-8c6f-5p8f
Security:       GHSA-ph27-3m5q-mj5m
Security:       GHSA-q9fr-m7g8-6ph5

    [10 lines not shown]
DeltaFile
+14-14net/asterisk20/files/patch-build__tools_make__xml__documentation
+5-5net/asterisk20/distinfo
+2-2net/asterisk20/Makefile
+1-0net/asterisk20/pkg-plist
+22-214 files

LLVM/project f386116llvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/test/Transforms/SLPVectorizer/X86 reduction-copyable-reused-scalars.ll

[SLP] Apply reused-scalar reduction counters at the vectorized lane

The horizontal reduction reuse-counter scale was placed by deduplicated
candidate order, but the emitted reduction vector lane order is defined by
the root node, which may be reordered or split (SplitVectorize). As a
result a repeat count could be applied to the wrong lane, producing a wrong
reduction result. Place each counter at the lane the matching candidate is
vectorized to.

Fixes #206476

Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/206611
DeltaFile
+11-24llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+1-1llvm/test/Transforms/SLPVectorizer/X86/reduction-copyable-reused-scalars.ll
+12-252 files

LLVM/project 8af496eutils/bazel/llvm-project-overlay/mlir BUILD.bazel, utils/bazel/llvm-project-overlay/mlir/test BUILD.bazel

[mlir] Bazel fix for #206520 (#206609)

I broke the bazel build in #206520 and pushed an incorrect fix in
#206599 which this PR also reverts.
DeltaFile
+4-1utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
+0-4utils/bazel/llvm-project-overlay/mlir/test/BUILD.bazel
+4-52 files

LLVM/project 148b8caclang/include/clang/CIR/Dialect/IR CIROps.td, clang/lib/CIR/CodeGen CIRGenBuiltin.cpp

[CIR] Support __builtin_nondeterministic_value (#206149)

Add a new CIR Op, FreezeOp, and use it to handle __builtin_nondeterministic_value
DeltaFile
+68-0clang/test/CIR/CodeGenBuiltins/builtin-nondeterministic-value.c
+29-0clang/include/clang/CIR/Dialect/IR/CIROps.td
+7-2clang/lib/CIR/CodeGen/CIRGenBuiltin.cpp
+104-23 files

LLVM/project f3b3d7dllvm/test/Analysis/CostModel/AMDGPU canonicalize.ll fsub.ll

[AMDGPU] Autogen checks for tests in AMDGPU Cost Model. NFC (#206595)

Even though there are comments in the test files saying checks
are autogenerated, it seems some checks are not actually updated. 
This work autogenerates checks based on the latest llvm source.
DeltaFile
+65-43llvm/test/Analysis/CostModel/AMDGPU/canonicalize.ll
+68-1llvm/test/Analysis/CostModel/AMDGPU/fsub.ll
+20-42llvm/test/Analysis/CostModel/AMDGPU/fround.ll
+4-4llvm/test/Analysis/CostModel/AMDGPU/control-flow.ll
+157-904 files

OpenZFS/src 0d1f3b1module/zfs vdev_raidz.c

RAIDZ: Fix parity regeneration/check condition

Profiling RAIDZ1/dRAID1 resilver I've noticed that they calculate
the parity twice for most of blocks: first to reconstruct the data
column and then to "verify" the parity column.  Same time it is
obvious that parity generated from data reconstructed from the
parity will be identical to the original.  The code even had this
condition, but it was overridden by ZIO_FLAG_RESILVER check.

I think the ZIO_FLAG_RESILVER condition is not right.  Instead we
should check for parity_errors > 0, when we failed to read some
parity columns that we'll need to rewrite.  It should not matter
if we are resilvering or just doing self healing on regular read.

Profiling shows this saving ~16% of ZFS CPU time when resilvering
RAIDZ1.  RAIDZ2+ are out of luck, unless two disks are replaced
same time, since there is still a parity to verify.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #18707
DeltaFile
+13-5module/zfs/vdev_raidz.c
+13-51 files

LLVM/project 04af344lld/COFF ICF.cpp

clang-format
DeltaFile
+3-6lld/COFF/ICF.cpp
+3-61 files

LLVM/project cc69878utils/bazel/llvm-project-overlay/mlir/test BUILD.bazel

[mlir][bazel] fix TestAnalysis deps (#206599)

Separating build fixes from #206520
DeltaFile
+4-0utils/bazel/llvm-project-overlay/mlir/test/BUILD.bazel
+4-01 files

LLVM/project 3349d8emlir/include/mlir/Dialect/LLVMIR/Transforms OptimizeForNVVM.h, mlir/include/mlir/Dialect/NVVM/Transforms Passes.h OptimizeForNVVM.h

[NFC][mlir][nvvm] move OptimizeForNVVM to its own directory (#206520)

This change moves the NVVM optimizations in the LLVM Dialect directory
to a dedicated `mlir/lib/Dialect/NVVM/Transforms/` directory.

Cf.
https://discourse.llvm.org/t/rfc-separate-gpu-specific-transforms-from-llvmirtransforms/91151
DeltaFile
+101-0mlir/lib/Dialect/NVVM/Transforms/OptimizeForNVVM.cpp
+0-101mlir/lib/Dialect/LLVMIR/Transforms/OptimizeForNVVM.cpp
+29-0utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
+26-0mlir/include/mlir/Dialect/NVVM/Transforms/Passes.h
+0-22mlir/include/mlir/Dialect/LLVMIR/Transforms/OptimizeForNVVM.h
+22-0mlir/include/mlir/Dialect/NVVM/Transforms/OptimizeForNVVM.h
+178-12312 files not shown
+227-13018 files

LLVM/project bcad6a0clang/tools/libclang CLog.h, llvm/include/llvm/Support raw_ostream.h

[llvm][clang] Remove `format_object_base` forward declarations (#206526)

PR https://github.com/llvm/llvm-project/pull/206319 removed the
`format_object_base` class itself, but not some of its
forward-declarations. NFCI
DeltaFile
+0-4clang/tools/libclang/CLog.h
+0-1llvm/include/llvm/Support/raw_ostream.h
+0-52 files

LLVM/project bce4b9cclang/docs UsersManual.rst, clang/include/clang/Basic AttrDocs.td

[clang][docs]Refactor compiler standard references from c94 to C95 (#206403)

The patch changes references to a non existent c94 standard from
to C95 (C90 + AMD1)

Closes #206389
DeltaFile
+2-2clang/docs/UsersManual.rst
+1-1clang/include/clang/Basic/AttrDocs.td
+3-32 files

LLVM/project fa7c714llvm/lib/Transforms/Utils LoopUtils.cpp, llvm/test/Transforms/LoopVectorize runtime-checks-diff-wrap-i32-address-space.ll

Address potential `IC * AbsCommonStrideInBytes` truncation
DeltaFile
+47-0llvm/test/Transforms/LoopVectorize/runtime-checks-diff-wrap-i32-address-space.ll
+10-2llvm/lib/Transforms/Utils/LoopUtils.cpp
+57-22 files

LLVM/project 4bc5abellvm/test/Analysis/LoopAccessAnalysis runtime-checks-large_step.ll

Add a test for 2^64 IV step
DeltaFile
+47-0llvm/test/Analysis/LoopAccessAnalysis/runtime-checks-large_step.ll
+47-01 files

LLVM/project f6a0623clang/include/clang/ScalableStaticAnalysis BuiltinAnchorSources.def, clang/include/clang/ScalableStaticAnalysis/Analyses/OperatorNewDelete OperatorNewDeletePointers.h

[SSAF][Extractor][Do not merge] Extract operator new/delete overload entities that shall retain their types

This commit creates an extractor for operator new/delete overloads.

Overloads of operator new shall retain their void* return type,
regardless of whether they are propagated by unsafe buffers. The same
applies to the parameters of operator delete overloads.

Therefore, clang-reforge eventually need this information.

rdar://179151541
DeltaFile
+260-0clang/unittests/ScalableStaticAnalysis/Analyses/OperatorNewDelete/OperatorNewDeletePointersExtractorTest.cpp
+119-0clang/lib/ScalableStaticAnalysis/Analyses/OperatorNewDelete/OperatorNewDeletePointersExtractor.cpp
+56-0clang/include/clang/ScalableStaticAnalysis/Analyses/OperatorNewDelete/OperatorNewDeletePointers.h
+9-5clang/lib/ScalableStaticAnalysis/Analyses/SSAFAnalysesCommon.h
+1-0clang/include/clang/ScalableStaticAnalysis/BuiltinAnchorSources.def
+1-0clang/lib/ScalableStaticAnalysis/Analyses/CMakeLists.txt
+446-51 files not shown
+447-57 files

FreeBSD/ports 023f86dsysutils/spiped Makefile, sysutils/spiped/files spiped.in

sysutils/spiped: Clean up UNIX sockets

When a TCP socket is closed, it becomes possible to create a new
socket listening on the same address; the behaviour of UNIX (aka
"local") sockets is different, in that an inode remains even after
it is closed, and blocks the creation of a new socket with the same
address.

When spiped is launched with a UNIX socket as its source address,
delete any existing socket with that address first.  This makes it
possible to "service spiped restart" when UNIX sockets are used.

Deleting the socket when stopping spiped would also work for the
case of restarting the daemon, but not for the case of starting the
daemon after an unclean system shutdown; so deleting only prior to
starting the daemon seemed like the better option.

PR:     295432
Reported by:    feld
DeltaFile
+5-0sysutils/spiped/files/spiped.in
+1-0sysutils/spiped/Makefile
+6-02 files

LLVM/project cc8549dllvm/lib/Transforms/Vectorize VPlan.h

[VPlan] Remove unused InductionDescriptor VPDerivedIVRecipe constructor (#206583)

Both callers use the 5-argument (Kind, FPBinOp, ...) constructor; the
delegating InductionDescriptor overload has no users.
DeltaFile
+0-7llvm/lib/Transforms/Vectorize/VPlan.h
+0-71 files

LLVM/project d5e975dflang/lib/Semantics openmp-utils.cpp

[flang][OpenMP] Add explicit return type to visitor lambdas (#206588)

This should silence MSVC (14.51.36231) error:
error C2338: static assertion failed: 'visit() requires the result of
all potential invocations to have the same type and value category
(N4950 [variant.visit]/5).'

e.g. https://lab.llvm.org/buildbot/#/builders/166/builds/9664
DeltaFile
+4-2flang/lib/Semantics/openmp-utils.cpp
+4-21 files

LLVM/project 8cf09c5lldb/include/lldb/Core BugReporter.h, lldb/source/Commands CommandObjectDiagnostics.cpp

[lldb] Add a BugReporter plugin type and "diagnostics report" (#206578)

Introduce a BugReporter plugin kind that files an assembled
Diagnostics::Report through a pluggable destination, plus a "diagnostics
report" command (aliased "bugreport") that collects the bundle and files
it through the first registered reporter.

CreateBugReporterInstance() returns the first registered reporter, so a
reporter registered earlier wins and a downstream tree can take over by
registering ahead of the built-ins. BugReporterNone is the
always-registered, last-in-order fallback. Its File() returns an error
pointing at LLDB_BUG_REPORT_URL, so the command surfaces "no tracker
configured" through the normal error path instead of special-casing it.

"diagnostics report" writes the bundle, prints a review warning, and
files it unless --no-open is given. The upcoming GitHub reporter, gated
by a CMake option, is the first real destination.
DeltaFile
+120-0lldb/source/Commands/CommandObjectDiagnostics.cpp
+52-0lldb/source/Core/PluginManager.cpp
+34-0lldb/source/Plugins/BugReporter/None/BugReporterNone.cpp
+32-0lldb/source/Plugins/BugReporter/None/BugReporterNone.h
+29-0lldb/include/lldb/Core/BugReporter.h
+26-0lldb/test/Shell/Diagnostics/TestReport.test
+293-08 files not shown
+340-014 files

LLVM/project 8fbed56llvm/lib/Transforms/Vectorize VPlanTransforms.cpp VPlanTransforms.h

[VPlan] Pass CostCtx to makeMemOpWideningDecisions (NFC). (#206580)

makeMemOpWideningDecisions already uses 2 members (PSE, L) and will need
more in the future. Direcly pass CostCtx.
DeltaFile
+7-6llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+1-2llvm/lib/Transforms/Vectorize/VPlanTransforms.h
+1-1llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+9-93 files

LLVM/project 78f4fe1llvm/test/CodeGen/AMDGPU target-cpu.ll

AMDGPU: Rewrite target-cpu test for new subarches

The function subtargets should now be a valid subtarget for
the top-level subarch.
DeltaFile
+52-74llvm/test/CodeGen/AMDGPU/target-cpu.ll
+52-741 files

LLVM/project b35d5b0llvm/unittests/CodeGen AMDGPUMetadataTest.cpp, llvm/unittests/CodeGen/GlobalISel GISelMITest.cpp

AMDGPU: Migrate unittests to subarch triples

Replace specifying a processor name with the triple
subarch.

The register-limit helpers in AMDGPUUnitTests.cpp that enumerate every
valid CPU via fillValidArchListAMDGCN still pass the CPU explicitly, as
does the MC Disassembler smoke test (its C disassembler API derives the
subtarget from the CPU, not the triple subarch).

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+6-6llvm/unittests/MC/AMDGPU/DwarfRegMappings.cpp
+6-6llvm/unittests/Target/AMDGPU/DwarfRegMappings.cpp
+3-3llvm/unittests/CodeGen/AMDGPUMetadataTest.cpp
+2-2llvm/unittests/Target/AMDGPU/AMDGPUUnitTests.cpp
+2-2llvm/unittests/CodeGen/GlobalISel/GISelMITest.cpp
+2-2llvm/unittests/MC/AMDGPU/Disassembler.cpp
+21-2110 files not shown
+33-3316 files

LLVM/project 1d19c84clang/lib/Basic OffloadArch.cpp, clang/lib/Driver Driver.cpp

clang: Start using new amdgpu subarch triples

Fixup invocations using --target=amdgcn + -mcpu to introduce
the subarch in the triple.

For offload toolchains, a single toolchain is constructed for the
top level amdgpu architecture, and the effective triple is used for
target specific tool invocations.

The specifics of the resource directory layout are tbd. This does
try to find resources in the subarch named directory. The paths
are searched at toolchain creation time, so that does not work
when there are multiple subarches.

Fixes #154925
DeltaFile
+234-2clang/lib/Basic/OffloadArch.cpp
+59-59clang/test/Driver/offload-arch-translation-amdgpu.cu
+43-43clang/test/Driver/hip-phases.hip
+33-33clang/test/Driver/hip-binding.hip
+49-15clang/lib/Driver/ToolChains/CommonArgs.cpp
+43-12clang/lib/Driver/Driver.cpp
+461-164103 files not shown
+1,251-491109 files

LLVM/project 6b092c7llvm/test/CodeGen/AMDGPU directive-amdgcn-target-legacy-triples.ll directive-amdgcn-target.ll

AMDGPU: Migrate target id tests to use new subarch triples
DeltaFile
+239-0llvm/test/CodeGen/AMDGPU/directive-amdgcn-target-legacy-triples.ll
+0-239llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
+11-11llvm/test/CodeGen/AMDGPU/tid-mul-func-xnack-any-on-2.ll
+12-10llvm/test/CodeGen/AMDGPU/target-id-xnack-always-on.ll
+11-11llvm/test/CodeGen/AMDGPU/tid-mul-func-xnack-all-any.ll
+11-11llvm/test/CodeGen/AMDGPU/tid-mul-func-xnack-all-not-supported.ll
+284-2829 files not shown
+380-37815 files

LLVM/project 978c702clang/lib/Driver/ToolChains CommonArgs.cpp, clang/test/Driver amdgpu-mcpu.cl hip-sanitize-options.hip

clang/AMDGPU: Stop passing redundant -target-cpu to cc1

Now that the exact target is encoded in the triple's subarch field,
-target-cpu is redundant. This avoids polluting the resultant IR with
unwanted "target-cpu" attributes. The net result is the desired codegen
when compiling libraries for a major subarch and linking it into a
program compiled for a specific arch. e.g., compiling for "gfx9-generic"
would pollute the IR with "target-cpu"="gfx9-generic", so codegen
would ultimately be performed for the generic target even after
linking into the concrete gfx9 cpu. The specialization will now be
achieved by merging the triples without the linker or optimization
passes needing to fixup function attributes.
DeltaFile
+62-62clang/test/Driver/amdgpu-mcpu.cl
+26-26clang/test/Driver/hip-sanitize-options.hip
+20-10clang/lib/Driver/ToolChains/CommonArgs.cpp
+12-16clang/test/Driver/hip-rdc-device-only.hip
+24-0clang/test/Preprocessor/amdgpu-subarch-cc1-target-cpu.cl
+10-10clang/test/Driver/amdgpu-xnack-sramecc-flags.c
+154-12427 files not shown
+214-21133 files

LLVM/project 293acbeclang/lib/Basic/Targets AMDGPU.h AMDGPU.cpp, clang/test/Misc/target-invalid-cpu-note amdgcn.c

clang/AMDGPU: Validate -target-cpu in cc1 is valid for the subarch

Restrict the reported list of valid target-cpus based on the triple's
subarch. This is more consistent with how other targets validate the
target CPU name. Currently we have split handling validating the target
name for the triple in both the driver and here. The driver based diagnostic
seems to be an amdgpu-ism in 2 different places (though there is one arm
validation emitting the same diagnostic). In the future we could probably
drop those.
DeltaFile
+55-0clang/test/Misc/target-invalid-cpu-note/amdgcn.c
+6-5clang/lib/Basic/Targets/AMDGPU.h
+1-1clang/lib/Basic/Targets/AMDGPU.cpp
+62-63 files