This removes some duplicate code. I suspect this was originally written
that way because vector::emplace didn't exist in C++03 mode, which
stopped being relevant when Clang implemented rvalue references in
C++03.
Symbols that get mapped into the read-only section are loaded as part of
the text segment and will always need a TOC entry to be addressable. Add
an option to aggressively merge these read only globals to reduce TOC
usage.
`-fvisibility-global-new-delete` has been added in Clang 18, so there is
no more need to specify the visibility of new/delete via libc++-internal
macros.
Some people used a custom new/delete, which requires them to have
default visibility, but didn't want to leak any symbols otherwise. Since
the new/delete visibility can now be controlled by a compiler flag,
there is no reason to set it with out macro.
https://reviews.llvm.org/D128007 originally tried to remove the option
to override the macro, but was partially reverted because people
actually set this specific macro.
It's checked in a cmake function that builds up a list called
`config_options`. But the check was appending to a list called
`compile_options`, so the intended `-DLIBC_MATH=whatever` didn't end up
on the actual compile command lines.
This PR fixes a crash in `VectorToGPU` when the operand of `extOp` is a
function argument, which cannot be retrieved using `getDefiningOp`.
Fixes#107967.
The lower bound information for the array members of a derived type
can't be obtained from the `DeclareOp`. It has to be extracted from the
`TypeInfoOp`. That was left as FIXME in the code. This PR adds the
missing functionality to fix the issue.
I tried the following approaches before settling on the current one that
is to generate `DITypeAttr` for array members right where the components
are being processed.
1. Generate a temp XDeclareOp with the shift information obtained from
the `TypeInfoOp`. This caused a few issues mostly related to
`unrealized_conversion_cast`.
2. Change the shift operands in the `declOp` that was passed in the
function before calling `convertType`. The code can be seen in the
abcf031a8e5a02f0081e7f293858302e7bf47bec. It essentially looked like the
following. It works correctly but I was not sure if temporarily changing
the `declOp` is the safe thing to do.
```
mlir::OperandRange originalShift = declOp.getShift();
mlir::MutableOperandRange mutableOpRange = declOp.getShiftMutable();
mutableOpRange.assign(shiftOpers);
elemTy = convertType(fieldTy, fileAttr, scope, declOp);
mutableOpRange.assign(originalShift);
```
Fixes#113178.
Member pointers refer to data or function members of a `CXXRecordDecl`,
which require a `MSInheritanceAttr` in order to be complete. Without that
we cannot calculate the size of a member pointer in memory. The attempt
has been causing a crash further down in the clang AST context. In order
to implement the feature, DWARF will need a new attribtue to convey the
information. For the moment, this patch teaches LLDB to handle to
situation and avoid the crash.
When instantiating "callable<T>", the "class CallableType" nested type
will only have a declaration in the copy for the instantiation - because
it's not refereed to directly by any other code that would need a
complete definition.
However, in the past, when conservative eval calling member function, we
took the static type of the "this" expr, and looked up the CXXRecordDecl
it refereed to to see if it has any mutable members (to decide if it
needs to refine invalidation or not). Unfortunately, that query needs a
definition, and it asserts otherwise, thus we crashed.
To fix this, we should consult the dynamic type of the object, because
that will have the definition.
I anyways added a check for "hasDefinition" just to be on the safe side.
Fixes#77378
Implement parsing of the AFFINITY clause on TASK construct, conversion
from the parser class to omp::Clause.
Lowering to HLFIR is unsupported, a TODO message is displayed.
This is a recommit of #107120 . The original PR was approved but failed
buildbot. The newly added tests should only be run for compilers that
support the ARM target. This has been resolved by adding a config file
for these tests.
- Pass optimizes memcpy's by padding out destinations and sources to a
full word to make ARM backend generate full word loads instead of
loading a single byte (ldrb) and/or half word (ldrh). Only pads
destination when it's a stack allocated constant size array and source
when it's constant string. Heuristic to decide whether to pad or not
is very basic and could be improved to allow more examples to be
padded.
- Pass works at the midend level
Fixes#112140
---
```
CXXConstructExpr 0x14209e580 'const S':'const struct S' contains-errors 'void (const int &)' list
`-CXXDefaultArgExpr 0x14209e500 'const int' contains-errors
`-RecoveryExpr 0x14209daf0 'const int' contains-errors
```
This change resolves an issue with evaluating `ArrayFiller` initializers
in _dependent_ contexts, especially when they involve a `RecoveryExpr`.
In certain cases, `ArrayFiller` initializers containing a `RecoveryExpr`
from earlier errors are incorrectly passed to `EvaluateInPlace`, causing
evaluation failures when they are value-dependent.
When this is the case, the initializer is processed through
`EvaluateDependentExpr`, which prevents unnecessary evaluation attempts
and ensures proper handling of value-dependent initializers in
`ArrayFillers`.
This patch adds assembly/disassembly for the following multi-vector SVE
instructions
- AESE (two/four registers)
- AESD (two/four registers)
- AESDIMC (two/four registers)
- AESEMC (two/four registers)
- Introduce assembler extension tests for the new Armv9.6 sve-aes2 and
ssve-aes features
- In accordance with:
https://developer.arm.com/documentation/ddi0602/latest/
Summary:
Before this change clang produced output with header unit names that may
conaint path separators, dots and other non-identifier characters. This
diff prints header unit name in quotes and -E output can be compiled
again. Also remove unnecessary space between header unit name and semi.
Test Plan: check-clang
This option applies for _import_ WPD (i.e., when `DevirtModule` pass
de-virtualizes according to an imported summary, in ThinLTO backend
pipeline). It's meant for debugging (e.g., bisection).
/llvm-project/clang/include/clang/Analysis/FlowSensitive/NoopLattice.h:49:2:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
}; // namespace llvm
These symbols will need to be explicitly exported for SandboxIRTests
when LLVM is built as shared library on window with explicitly
visibility macros are enabled.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows.
This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm as a DLL. The export macros used
here were added in #96630
Since shared library symbols aren't deduplicated across multiple
libraries on windows like Linux we have to manually explicitly import
and export `Any::TypeId` template instantiations for the uses of
`llvm::Any` in the LLVM codebase to support LLVM Windows shared library
builds.
This change ensures that external code, including LLVM's own tests, can
use PassManager callbacks when LLVM is built as a DLL.
I also removed the only use of llvm::Any for LoopNest that only existed
in debug code and there also doesn't seem to be any code creating
`Any<LoopNest>`
On WebAssembly, most coverage metadata contents read by llvm-cov (like
`__llvm_covmap` and `__llvm_covfun`) are stored in custom sections
because they are not referenced at runtime. However, `__llvm_prf_names`
is referenced at runtime by the profile runtime library and is read by
llvm-cov post-processing tools, so it needs to be stored in a data
segment, which is allocatable at runtime and accessible by tools as long
as "name" section is present in the binary.
This patch changes the way llvm-cov reads `__llvm_prf_names` on
WebAssembly. Instead of looking for a section, it looks for a data
segment with the same name.
This reverts commit 157f10ddf2d851125a85a71e530dc9d50cb032a2 and fixes
PE/COFF `.lprfn$A` section handling.
This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387.
This disables the IWYU mapping that caused the failure, since
the headers aren't reachable for now.
This is the first part of the "Freezing C++03 headers" proposal
explained in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319/58.
This patch mechanically copies the headers as of the LLVM 19.1 release
into a subdirectory of libc++ so that we can start using these headers
when building in C++03 mode. We are going to be backporting important
changes to that copy of the headers until the LLVM 21 release. After the
LLVM 21 release, only critical bugfixes will be fixed in the C++03 copy
of the headers.
This patch only performs a copy of the headers -- these headers are
still unused by the rest of the codebase.
In some cases, Previous (and its operands) can be hoisted. This allows
supporting additional cases where sinking of all users of to FOR fails,
e.g. due having to sink recipes with side-effects.
This fixes a crash where we fail to create a scalar VPlan for a
first-order recurrence, but can create a vector VPlan, because the trunc
instruction of an IV which generates the previous value of the
recurrence has been optimized to a truncated induction recipe, thus
hoisting it to the beginning.
Fixes https://github.com/llvm/llvm-project/issues/106523.
PR: https://github.com/llvm/llvm-project/pull/108945
Some of the profile test files fail if they have CRLF newlines;
add a .gitattributes file that forces them to be checked out
with LF newlines, regarless of the user Git configuration.
These text files get embedded verbatim in
llvm/test/tools/llvm-rc/tag-html.test, so their newlines form needs to
match the expected form exactly.
This reverts commit 2fdf49db7562eadbe01b18f0d01a955cd41b94ea, as that
change no longer should be necessary. (At the time, buildbots had
checkouts with all files having CRLF, and those don't get updated even
if the toplevel .gitattributes were reverted in
e669bbbb7265a7d4d59bac2d3889194efa167ea8. Now those buildbots have
gotten fresh checkouts with all files having the right line endings.)
The std::prev function appeared to work on non Cpp17BidirectionalIterators, however it
behaved strangely by being the identity function. That was extremely misleading and
potentially dangerous, since several recent iterators that are C++20 bidirectional_iterators
don't satisfy the Cpp17BidirectionalIterator named requirement. For example:
auto zv = std::views::zip(vec1, vec2);
auto it = zv.begin() + 5;
auto it2 = std::prev(it); // "it2" will be the same as "it", instead of the previous one
Here, zip_view::iterator is a c++20 random_access_iterator, but it only satisfies the
Cpp17InputIterator named requirement because its reference type is a proxy type. Hence
`std::prev` would silently accept that iterator but it would do a no-op instead of going
to the previous position.
This patch changes `std::prev(it)` to produce an error at compile-time when instantiated
with a type that is not a Cpp17BidirectionalIterator.
Fixes#109456
