This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and c243406a695ca056a07ef4064b0f9feee7685320, see discussion in https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
MSVC supports an extension allowing to delete an array of objects via pointer whose static type doesn't match its dynamic type. This is done via generation of special destructors - vector deleting destructors. MSVC's virtual tables always contain a pointer to the vector deleting destructor for classes with virtual destructors, so not having this extension implemented causes clang to generate code that is not compatible with the code generated by MSVC, because clang always puts a pointer to a scalar deleting destructor to the vtable. As a bonus the deletion of an array of polymorphic object will work just like it does with MSVC - no memory leaks and correct destructors are called. This patch will cause clang to emit code that is compatible with code produced by MSVC but not compatible with code produced with clang of older versions, so the new behavior can be disabled via passing -fclang-abi-compat=21 (or lower). This is yet another attempt to land vector deleting destructors support originally implemented by https://github.com/llvm/llvm-project/pull/133451. This PR contains fixes for issues reported in the original PR as well as fixes for issues related to operator delete[] search reported in several issues like https://github.com/llvm/llvm-project/pull/133950#issuecomment-2787510484 https://github.com/llvm/llvm-project/issues/134265 Fixes https://github.com/llvm/llvm-project/issues/19772
Similar to previous no transitive changes to decls, types, identifiers and source locations ( https://github.com/llvm/llvm-project/pull/92083 https://github.com/llvm/llvm-project/pull/92085 https://github.com/llvm/llvm-project/pull/92511 https://github.com/llvm/llvm-project/pull/86912 ) This patch does the same thing for MacroID and PreprocessedEntityID. --- ### Some background Previously we record different IDs linearly. That is, when writing a module, if we have 17 decls in imported modules, the ID of decls in the module will start from 18. This makes the contents of the BMI changes if the we add/remove any decls, types, identifiers and source locations in the imported modules. This makes it hard for us to reduce recompilations with modules. We want to skip recompilations as we think the modules can help us to remove fake dependencies. This can be done by split the ID into <ModuleIndex, LocalIndex> pairs. This is ALREADY done for several different ID above. We call it non-casacading changes (https://clang.llvm.org/docs/StandardCPlusPlusModules.html#experimental-non-cascading-changes). Our internal users have already used this feature and it works well for years. Now we want to extend this to MacroID and PreprocessedEntityID. This is helpful for us in the downstream as we allowed named modules to export macros. But I believe this is also helpful for header-like modules if you'd like to explore the area. And also I think this is a nice cleanup too. --- Given the use of MacroID and PreprocessedEntityID are not as complicated as other IDs in the above series, I feel the patch itself should be good. I hope the vendors can test the patch to make sure it won't affect existing users.
Close https://github.com/llvm/llvm-project/issues/166068 The cause of the problem is that we would import initializers and pending implicit instantiations from other named module. This is very bad and it may waste a lot of time. And we didn't observe it as the weak symbols can live together and the strong symbols would be removed by other mechanism. So we didn't observe the bad behavior for a long time. But it indeeds waste compilation time.
This PR adds support for the `dyn_groupprivate` clause, which will be part of OpenMP 6.1. This feature allows users to request dynamic shared memory on target regions. --------- Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>
Fixes #165445. Fixes a crash when `ASTWriter::GenerateNameLookupTable` processes enum constants from C++20 header units. The special handling for enum constants, introduced in fccc6ee, doesn't account for declarations whose owning module is a C++20 header unit. It calls `isNamedModule()` on the result of `getTopLevelOwningNamedModule()`, which returns null for header units, causing a null pointer dereference.
Initial parsing/sema/codegen support for threadset clause in task and taskloop directives [Section 14.8 in in OpenMP 6.0 spec] ---------
This PR enhances the OpenMP `nowait` clause implementation by adding support for optional argument in both parsing and semantic analysis phases. Reference: 1. OpenMP 6.0 Specification, page 481
This is the first patch of a handful to get the reduction combiner recipe lowering properly. THIS patch is NFC as it doesn't actually change anything except the structure of the AST. For each 'combiner' recipe we need a 'LHS' 'RHS' and expression to represent the operation. Each var-reference can have 1 or more combiners. IF it is a plain scalar, or a struct with the proper operator, or an array of either of those, there will be 1. HOWEVER, aggregates without the proper operator are supposed to be broken down and done from their elements (which can only be scalars). In this case, we will represent 1 'combiner' recipe per field-decl. This patch only puts the infrastructure in place to do so, future patches wll do the work to fill this in.
I originally expected that we were going to need the initExpr stored separately from the allocaDecl when doing arrays/pointers, however after implementing it, we found that the idea of having the allocaDecl just store its init directly still works perfectly. This patch removes the extra field from the AST.