[Clang][OpenMP] Make test use clang_cc1 (#169233)
This test does not actually need to use the clang driver. Using the
driver means that the environment plays much more into the tests
results. We ran into a situation where the driver decided not to pass
-fopenmp to the cc1 invocation, causing the test to fail.
This also makes the test more consistent with the other OpenMP tests and
should make it slightly faster (no subprocess invocation).
[lldb] Fix SWIG bug detection in CMake (#169212)
The CMake
[`set()`](https://cmake.org/cmake/help/latest/command/set.html) command
does not accept a conditional expression as a value. As a result,
AFFECTED_BY_SWIG_BUG was being set to a string representation of the
condition rather than a boolean value, causing it to always evaluate as
truthy in subsequent if-checks.
[CIR] Add builtin operator new/delete (#168578)
This PR adds `__builtin_operator_new` and `__builtin_operator_delete`.
The implementation is taken from clang code gen.
[AArch64] Mark FMOVvXfY_ns as rematerializable, cheap
Otherwise, the register allocator may spill and reload constants that
can be rematerialized with a single instruction.
[AArch64] Mark FMOVvXfY_ns as rematerializable, cheap
Otherwise, the register allocator may spill and reload constants that
can be rematerialized with a single instruction.
[clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)
This removes the dependency on clangDriver from clangFrontend and
flangFrontend.
This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.
This change was discussed in the following RFC:
https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773
[AArch64] Mark FMOVvXfY_ns as rematerializable, cheap
Otherwise, the register allocator may spill and reload constants that
can be rematerialized with a single instruction.
[X86] X86ISelDAGToDAG - don't let ADD/SUB(X,1) -> SUB/ADD(X,-1) constant fold (#169217)
Extension to #168726 - ensure we peek through bitcasts to look for
constants (as constant folding will)
DAG should have constant folded this, but we're still fighting the lack
of proper topological sorting.
Fixes #169205
[flang][OpenMP] Better diagnostics for invalid or misplaced directives (#168885)
Add two more AST nodes, one for a misplaced end-directive, and one for
an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ").
Emit error messages when either node is encountered in semantic
analysis.
[analyzer] Fix [[clang::suppress]] for template instantiations (#168954)
BugSuppression works by traversing the lexical decl context of the
decl-with-issue to record what source ranges should be suppressed by
some attribute.
Note that the decl-with-issue will be changed to the lexical decl
context of the original decl-with-issue, to make suppression attributes
work that were attached to the CXXRecordDecl containing the
CXXMethodDecl (bug report's DeclWithIssue).
It happens so that it uses a DynamicRecursiveASTVisitor, which has a
couple of traversal options. Namely:
- ShouldVisitTemplateInstantiations
- ShouldWalkTypesOfTypeLocs
- ShouldVisitImplicitCode
- ShouldVisitLambdaBody
By default, these have the correct values, except for
[7 lines not shown]
[RISCV] Support zilsd-4byte-align for i64 load/store in SelectionDAG. (#169182)
I think we need to keep the SelectionDAG code for volatile load/store so
we should support 4 byte alignment when possible.
Revert "[RegAlloc] Fix the terminal rule check for interfere with DstReg (#168661)"
This reverts commit 0859ac5866a0228f5607dd329f83f4a9622dedcc.
This caused a couple test failures, likely due to a mid-air collision.
Reverting for now to get the tree back to green and allow the original
author to run UTC/friends and verify the output.
Don't mark lambda non-dependent if nested in a generic lambda. (#149121)
Fixes #118187
Fixes #156579
An instantiated `LambdaExpr` can currently be marked as
`LDK_NeverDependent` if it's nested within a generic lambda. If that
`LambdaExpr` in fact depends on template parameters introduced by the
enclosing generic lambda, then its dependence will be misreported as
"never dependent" and spurious diagnostics can result.
The fix here proposed is a bit ugly, but the condition that it's being
bolted onto already seems like a bit of a hack, so this seems no worse
for wear.
Note that #89702 surfaced this change because it caused the inner lambda
expression to (correctly) be considered in a constant-evaluated context.
The affected check for whether to mark the inner lambda as
`LDK_NeverDependent` therefore started to apply, whereas it didn't
[2 lines not shown]
[RegAlloc] Fix the terminal rule check for interfere with DstReg (#168661)
This maybe a bug which is introduced by commit
6749ae36b4a33769e7a77cf812d7cd0a908ae3b9, and has been present ever
since.
In this case, `OtherReg` always overlaps with `DstReg` cause they from
the `Copy` all.
