When checking deduction consistency, a substitution can be incomplete
such that only sugar parts refer to non-deduced template parameters.
This would not otherwise lead to an inconsistent deduction, so this
patch makes it so we canonicalize the types before substitution in order
to avoid that possibility, for now.
When we are able to produce substitution failure diagnostics for partial
ordering, we might want to improve the TemplateInstantiator so that it
does not fail in that case.
This fixes a regression on top of #100692, which was reported on the PR.
This was never released, so there are no release notes.
For `libomp` on AIX, we build shared object `libomp.so` first and then
archive it into `libomp.a`. Due to a CMake for AIX problem, the install
step also tries to publish `libomp.so`. While we use a script to build
`libomp.a` out-of-tree for Clang and avoided the problem, this chokes
the in-tree build for Flang. The issue will be reported to CMake but
before a fixed CMake is available, this patch ensures only `libomp.a` is
published.
Making the existing populateGpuLowerSubgroupReduceToShufflePatterns()
function also cover the new "clustered" subgroup reductions is proving
to be inconvenient, because certain backends may have more specific
lowerings that only cover the non-clustered type, and this creates pass
ordering constraints. This commit removes coverage of clustered
reductions from this function in favour of a new separate function,
which makes controlling the lowering much more straightforward.
The order of operations in name resolution wasn't converting named
entities to objects by the time that they were subjected to the implicit
typing rules in the case of interface blocks. This led to entities
remaining untyped without error, leading to a crash in module file
generation.
Fixes https://github.com/llvm/llvm-project/issues/108975.
When an OPEN statement fails, a unit that was created for the OPEN needs
to be removed from the unit map. The code that tried to do this was
incorrect -- it needs to re-acquire the unit via LookUpForClose as a
CLOSE statement does. (The failure to do this completely was leaving a
zombie unit active that could break a later OPEN on the same unit
number.)
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
This check will now work out of the box with other containers that have a
`contains` method, such as `folly::F14` or Abseil containers.
It will also work with strings, which are basically just weird containers.
`std::string` and `std::string_view` will have a `contains` method starting with
C++23. `llvm::StringRef` and `folly::StringPiece` are examples of existing
implementations with a `contains` method.
As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
Same we way mark a path unreachable if it may cause a nullptr
dereference, div/rem by zero or signed div/rem of INT_MIN by -1 cause
immediate UB.
Closes#109008
`std::complex` operators do not work for the CUDA device compilation
of F18 runtime. This change makes use of `cuda::std::complex` from
`libcudacxx`.
`cuda::std::complex` does not have specializations for `long double`,
so the change is accompanied with a clean-up for `long double` usage.
When diagnosing register bindings we just need to make sure there is a
resource that matches the provided register type. We can emit the
diagnostics right away instead of collecting flags in the
RegisterBindingFlags struct. That also enables early exit when scanning
user defined types because we can return as soon as we find a matching
resource for the given register type.
Otherwise, the enum defaults to 'int'. Update a few places that used
'int' for registers that now need to change to avoid a signed/unsigned
compare warning.
I was hoping this would allow us to remove the 'int' comparison
operators in Register.h and MCRegister.h, but compares with literal 0
still need them.
Use a setne with 0 instead of a trunc. We know we zero extended the node
so we can get by with a non-zero check only. The truncate lowering
doesn't know that we zero extended so has to mask the lsb.
I don't think DAG combine sees the trunc before we lower it to RISCVISD
nodes so we don't get a chance to use computeKnownBits to remove the
AND.
Current implementation of X86 Domain Reassignment pass is finding out
the complete closure of a general register, then check if it's possible
to change the domain. It causes compile time issue when compiling large
functions. This patch checks the possibility of change domain in the
process of constructing closure, if it's illegal to change domain, we
can return immedietely.
For one of our large files, it reduced X86 Domain Reassignment pass time
from 200+ seconds to less than 1s.
Resolves: #70930 (and probably latest comments from clangd/clangd#251)
by fixing racing for the shared DiagStorage value which caused messing with args inside the storage and then formatting the following message with getArgSInt(1) == 2:
def err_module_odr_violation_function : Error<
"%q0 has different definitions in different modules; "
"%select{definition in module '%2'|defined here}1 "
"first difference is "
which causes HandleSelectModifier to go beyond the ArgumentLen so the recursive call to FormatDiagnostic was made with DiagStr > DiagEnd that leads to infinite while (DiagStr != DiagEnd).
The Main Idea:
Reuse the existing DiagStorageAllocator logic to make all DiagnosticBuilders having independent states.
Also, encapsulating the rest of state (e.g. ID and Loc) into DiagnosticBuilder.
The last attempt failed -
https://github.com/llvm/llvm-project/pull/108187#issuecomment-2353122096
so was reverted - #108838
`WASM_MEMORY_ADDR_REL_` and `WASM_TABLE_INDEX_REL_` relocations against
**undefined symbols** are not supported and, except for
`UnresolvedPolicy::ReportError`, lead to incorrect Wasm code, such as
invalid data address or invalid table index that cannot be patched
during later dynamic Wasm linking with modules declaring those symbols.
This is different to other relocations that support undefined symbols by
declaring correspond Wasm imports.
For more robust behavior, `wasm-ld` should probably report an error for
such unsupported PIC relocations, independent of the `UnresolvedPolicy`.
Summary:
This PR fixes the issue where the VecLib bitfield in CodeGenOptions.def
is too small to accommodate the increasing number of vector libraries.
Specifically, the bitfield size was previously set to 3, but with the
introduction of more vector libraries (currently 9), the bitfield needed
to be expanded to avoid potential issues in vectorization.
In this PR, I have increased the size of the VecLib bitfield from 3 to 4
to account for the additional libraries. This ensures that all 9 vector
libraries are correctly encoded and available for use without errors.
Changes Made:
Modified: Increased the VecLib bitfield size from 3 to 4 in
clang/include/clang/Basic/CodeGenOptions.def.
Motivation:
This change is necessary to ensure that all vector libraries are
properly represented and selectable. The current limitation of the
VecLib bitfield size was causing some vectorization opportunities to be
lost when more than 3 bits were needed to represent the library options.
Closes:
Fixes https://github.com/llvm/llvm-project/issues/108704
Add new elementwise popcount builtin to support HLSL function
'countbits'.
elementwise popcount only accepts integer types.
Add hlsl intrinsic 'countbits'
Closes#99094
So far, the test case was also testing the offset -1. This test cases
failed if the string is immediately at the beginning of the memory
region, though, and the offset -1 hence belonged to a different memory
region.
The fix is rather straightforward:
Passing an offset of -1 is not used by any actual clients of lldb-dap,
anyway. As such, this commit simply removes the corresponding test case.
