| Age | Commit message (Collapse) | Author |
|---|
|
(#169116)
This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
|
|
(#168840)
Consider a newly added "malloc_span" attribute in the allocation token
instrumentation to ensure that allocation functions with the
"malloc_span" attribute are processed similarly to other memory
allocation functions.
Update the tests to demonstrate applicability to __size_returning_new.
|
|
(#167758)
This fixes the issue reported in
https://github.com/llvm/llvm-project/pull/166855#issuecomment-3518604073
that had been revealed after
https://github.com/llvm/llvm-project/pull/166855 was merged.
`CodeGenFunction::GenerateVarArgsThunk` creates thunks for vararg
functions by cloning and modifying them. It is different from
`CodeGenFunction::generateThunk`, which is used for Itanium ABI.
According to https://reviews.llvm.org/D39396,
`CodeGenFunction::GenerateVarArgsThunk` may be called before metadata
nodes are resolved. So, it tries to avoid remapping DISubprogram and all
metadata nodes it references inside `CloneFunction()` by manually
cloning DISubprogram.
If optimization level is not OptNone, DILocalVariables for a function
are saved in DISubprogram's retainedNodes field. When
`CodeGenFunction::GenerateVarArgsThunk` clones such DISubprogram without
remapping, it produces a subprogram with incorrectly-scoped retained
nodes. It triggers Verifier checks added in
https://github.com/llvm/llvm-project/pull/166855.
To solve that, retained nodes list of a cloned DISubprogram is cleared.
|
|
Add a new builtin function __builtin_bswapg. It works on any integral
types that has a multiple of 16 bits as well as a single byte.
Closes #160266
|
|
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
|
|
multiversion resolvers (#167516)
- Fixes https://github.com/llvm/llvm-project/issues/163369
- Segmentation fault occurred because resolver was calling TSan
instrumentation functions (__tsan_func_entry, __tsan_func_exit) but as
the resolver is run by the dynamic linker at load time, TSan is not
initialized yet so the current thread pointer is null.
- This PR adds the DisableSanitizerInstrumentation attribute to the
multiversion function resolvers to avoid issues like this.
- Added regression test for TSan segfault.
|
|
Fix AArch64 argument passing for C++ empty classes with large explicitly specified alignment
reproducer: https://godbolt.org/z/qsze8fqra
rel issue: https://github.com/llvm/llvm-project/issues/69872
rel commit: https://github.com/llvm/llvm-project/commit/1711cc930bda8d27e87a2092bd220c18e4600c98
|
|
(#166850)"
This reverts commit 5fc1b74af52093cd5229ba0e1c368d41735bb990.
This broke premerge (and premerge was failing on the patch itself):
1. https://lab.llvm.org/staging/#/builders/192/builds/10053
2. https://lab.llvm.org/staging/#/builders/21/builds/8268
|
|
This adds code that was previously missing from emitAutoVarAlloca to
identify when an aggregate auto var is being emitted with a constant
initializer, and the associated code that is called from emitAutoVarInit
to store the constant. This allows significantly more efficient
initialization.
|
|
With the C++23 explicit object parameter feature, it is no longer
sufficient to only check if a function is an instance method to
determine if it has an implicit this argument. That causes problems in
attributes that have parameter indexes.
|
|
A collection of small changes to get a number of lit tests working on
z/OS.
|
|
Currently Clang usually leaves padding bits uninitialized, which means
they are undef at the moment.
When expanding stores of vector types to include padding, the padding
lanes will be poison, hence the padding bits will be poison.
This interacts badly with coercion of arguments and return values, where
3 x float vectors will be loaded as i128 integer; poisoning the padding
bits will make the whole value poison.
Not sure if there's a better way, but I think we have a number of places
that currently rely on the padding being undef, not poison.
PR: https://github.com/llvm/llvm-project/pull/164821
|
|
(#156842)
Implement code generation for `__builtin_infer_alloc_token()`. The
`AllocToken` pass is now registered to run unconditionally in the
optimization pipeline. This ensures that all instances of the
`llvm.alloc.token.id` intrinsic are lowered to constant token IDs,
regardless of whether `-fsanitize=alloc-token` is enabled. This
guarantees that the builtin always resolves to a token value, providing
a consistent and reliable mechanism for compile-time token querying.
This completes `__builtin_infer_alloc_token(<malloc-args>, ...)` to
allow compile-time querying of the token ID, where the builtin arguments
mirror those normally passed to any allocation function. The argument
expressions are unevaluated operands. For type-based token modes, the
same type inference logic is used as for untyped allocation calls.
For example the ID that is passed to (with `-fsanitize=alloc-token`):
some_malloc(sizeof(Type), ...)
is equivalent to the token ID returned by
__builtin_infer_alloc_token(sizeof(Type), ...)
The builtin provides a mechanism to pass or compare token IDs in code
that needs to be explicitly allocation token-aware (such as inside an
allocator, or through wrapper macros).
A more concrete demonstration of __builtin_infer_alloc_token's use is
enabling type-aware Slab allocations in the Linux kernel:
https://lore.kernel.org/all/20250825154505.1558444-1-elver@google.com/
Notably, any kind of allocation-call rewriting is a poor fit for the
Linux kernel's kmalloc-family functions, which are macros that wrap
(multiple) layers of inline and non-inline wrapper functions. Given the
Linux kernel defines its own allocation APIs, the more explicit builtin
gives the right level of control over where the type inference happens
and the resulting token is passed.
|
|
This change enables validation checks against the following two ARM
atomic builtins:
```
__builtin_arm_ldrexd
__builtin_arm_strexd
```
Previously, no checks existed for these builtins, so under a release
compiler, it would be possible to emit `ldrexd`/`strexd` under ARM
targets which set the LDREX mask (returned via `getARMLDREXMask`) to
signify these as unsupported instructions.
For example, the following would compile with errors:
```c
> type atomics.c
long long func(void) {
long long num = 0;
__builtin_arm_strex(42, &num);
return __builtin_arm_ldrex(&num);
}
```
```
> clang --target=armv7m-linux-gnueabi -S atomics.c -o -
atomics.c:3:5: error: address argument to load or store exclusive builtin must be a pointer to 1,2
or 4 byte type ('volatile long long *' invalid)
3 | __builtin_arm_strex(42, &num);
| ^
atomics.c:4:12: error: address argument to load or store exclusive builtin must be a pointer to 1,2
or 4 byte type ('const volatile long long *' invalid)
4 | return __builtin_arm_ldrex(&num);
| ^
2 errors generated.
```
However, a similar program would compile without errors:
```c
> type atomics.c
long long func(void) {
long long num = 0;
__builtin_arm_strexd(42, &num);
return __builtin_arm_ldrexd(&num);
}
```
```
> clang --target=armv7m-linux-gnueabi -S atomics.c -o -
...
strexd r1, r2, r3, [r0]
ldrexd r0, r1, [r0]
...
```
With this change, we now have appropriate compile-time errors:
```
> clang --target=armv7m-linux-gnueabi -S atomics.c -o -
atomics.c:3:5: error: load and store exclusive builtins are not available on this architecture
3 | __builtin_arm_strexd(42, &num);
| ^ ~~~~
atomics.c:4:12: error: load and store exclusive builtins are not available on this architecture
4 | return __builtin_arm_ldrexd(&num);
| ^ ~~~~
2 errors generated.
```
|
|
Let Clang emit `llvm.tbaa.errno` metadata in order to let LLVM
carry out optimizations around errno-writing libcalls to, as
long as it is proved the involved memory location does not alias
`errno`.
Previous discussion: https://discourse.llvm.org/t/rfc-modelling-errno-memory-effects/82972.
|
|
results (#78707)
fixes #30023
The issue is that for compare exchange builtin, if the type's size is
not power of 2, it creates a temporary of size power of 2, then emit the
compare exchange operation. And later, the results of the compare
exchange operation has two components: 1. a boolean whether or not the
exchange happens. 2. the old value
we are supposed to write the old value into user's "expected" value.
However, in case the type is not power of 2, what we actually wrote to
is the temporary that was created.
The fix is to pass the "expected" address all the way down so it can
wrote to the correct address
|
|
For this specific case, when catching a pointer data type, by reference,
Clang generates a special code pattern, which directly accesses the
exception data by skipping past the `_Unwind_Exception` manually (rather
than using the return value of `__cxa_begin_catch`).
On most platforms, `_Unwind_Exception` is 32 bytes, but in some
configurations it's different. (ARM EHABI is one preexisting case.) In
the case of SEH, it's also different - it is 48 bytes in 32 bit mode and
64 bytes in 64 bit mode. (See the SEH ifdef in `_Unwind_Exception` in
`clang/lib/Headers/unwind.h`.)
Handle this case in `TargetCodeGenInfo::getSizeOfUnwindException`,
fixing the code generation for catching pointers by reference.
This fixes https://github.com/mstorsjo/llvm-mingw/issues/522.
|
|
For the AllocToken pass to accurately calculate token ID hints, we
need to attach `!alloc_token` metadata for allocation calls.
Unlike new expressions, untyped allocation calls (like `malloc`,
`calloc`, `::operator new(..)`, `__builtin_operator_new`, etc.) have no
syntactic type associated with them. For -fsanitize=alloc-token, type
hints are sufficient, and we can attempt to infer the type based on
common idioms.
When encountering allocation calls (with `__attribute__((malloc))` or
`__attribute__((alloc_size(..))`), attach `!alloc_token` by inferring
the allocated type from (a) sizeof argument expressions such as
`malloc(sizeof(MyType))`, and (b) casts such as `(MyType*)malloc(4096)`.
Note that non-standard allocation functions with these attributes are
not instrumented by default. Use `-fsanitize-alloc-token-extended` to
instrument them as well.
Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434
---
This change is part of the following series:
1. https://github.com/llvm/llvm-project/pull/160131
2. https://github.com/llvm/llvm-project/pull/156838
3. https://github.com/llvm/llvm-project/pull/162098
4. https://github.com/llvm/llvm-project/pull/162099
5. https://github.com/llvm/llvm-project/pull/156839
6. https://github.com/llvm/llvm-project/pull/156840
7. https://github.com/llvm/llvm-project/pull/156841
8. https://github.com/llvm/llvm-project/pull/156842
|
|
This fixes the transform to use the correct parameter type for an
AssociatedDecl which has been fully specialized.
Instead of using the type for the parameter of the specialized template,
this uses the type of the argument it has been specialized with.
This fixes a regression reported here:
https://github.com/llvm/llvm-project/pull/161029#issuecomment-3375478990
Since this regression was never released, there are no release notes.
|
|
Implement the TypeHashPointerSplit mode: This mode assigns a token ID
based on the hash of the allocated type's name, where the top half
ID-space is reserved for types that contain pointers and the bottom half
for types that do not contain pointers.
This mode with max tokens of 2 (`-falloc-token-max=2`) may also
be valuable for heap hardening strategies that simply separate pointer
types from non-pointer types.
Make it the new default mode.
Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434
---
This change is part of the following series:
1. https://github.com/llvm/llvm-project/pull/160131
2. https://github.com/llvm/llvm-project/pull/156838
3. https://github.com/llvm/llvm-project/pull/162098
4. https://github.com/llvm/llvm-project/pull/162099
5. https://github.com/llvm/llvm-project/pull/156839
6. https://github.com/llvm/llvm-project/pull/156840
7. https://github.com/llvm/llvm-project/pull/156841
8. https://github.com/llvm/llvm-project/pull/156842
|
|
Wire up the `-fsanitize=alloc-token` command-line option, hooking up
the `AllocToken` pass -- it provides allocation tokens to compatible
runtime allocators, enabling different heap organization strategies,
e.g. hardening schemes based on heap partitioning.
The instrumentation rewrites standard allocation calls into variants
that accept an additional `size_t token_id` argument. For example,
calls to `malloc(size)` become `__alloc_token_malloc(size, token_id)`,
and a C++ `new MyType` expression will call
`__alloc_token__Znwm(size, token_id)`.
Currently untyped allocation calls do not yet have `!alloc_token`
metadata, and therefore receive the fallback token only. This will be
fixed in subsequent changes through best-effort type-inference.
One benefit of the instrumentation approach is that it can be applied
transparently to large codebases, and scales in deployment as other
sanitizers.
Similarly to other sanitizers, instrumentation can selectively be
controlled using `__attribute__((no_sanitize("alloc-token")))`. Support
for sanitizer ignorelists to disable instrumentation for specific
functions or source files is implemented.
See clang/docs/AllocToken.rst for more usage instructions.
Link:
https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434
---
This change is part of the following series:
1. https://github.com/llvm/llvm-project/pull/160131
2. https://github.com/llvm/llvm-project/pull/156838
3. https://github.com/llvm/llvm-project/pull/162098
4. https://github.com/llvm/llvm-project/pull/162099
5. https://github.com/llvm/llvm-project/pull/156839
6. https://github.com/llvm/llvm-project/pull/156840
7. https://github.com/llvm/llvm-project/pull/156841
8. https://github.com/llvm/llvm-project/pull/156842
|
|
isEliminableCastPair() currently tries to support elimination of
ptrtoint/inttoptr cast pairs by assuming that the maximum possible
pointer size is 64 bits. Of course, this is no longer the case nowadays.
This PR changes isEliminableCastPair() to accept an optional DataLayout
argument, which is required to eliminate pointer casts.
This means that we no longer eliminate these cast pairs during ConstExpr
construction, and instead only do it during DL-aware constant folding.
This had a lot of annoying fallout on tests, most of which I've
addressed in advance of this change.
|
|
The frontend currently opens the path provided via
`-fprofile-instrument-use-path=` to learn the kind of the
instrumentation data and set the `CodeGenOptions::ProfileUse` value.
This happens during command-line parsing, where we don't have a
correctly configured VFS yet, so the behavior is quite different from
all other frontend inputs. We need to move this logic out of the
frontend command line parsing logic somewhere where we do have the
configured VFS.
The complication is that the `ProfileUse` flag is being used to set
preprocessor macros, and there isn't a great place between command line
parsing and preprocessor initialization to perform this logic.
This PR solves the issue by deducing the kind of instrumentation data
right in the driver and then passing it via a new flag to the frontend.
This shouldn't change observable behavior of Clang on the driver level,
and only affects the frontend command line interface, which is an
implementation detail anyway.
|
|
Define the __dmr2048 type to represent the DMR pair introduced by the
Dense Math Facility on PowerPC, and add three Clang builtins
corresponding to DMF cryptography:
__builtin_mma_dmsha2hash
__builtin_mma_dmsha3hash
__builtin_mma_dmxxshapad
The __dmr2048 type is required for the dmsha3hash crypto builtin, and,
as withother PPC MMA and DMR types, its use is strongly restricted.
|
|
AMDGCN flavoured SPIR-V allows AMDGCN specific builtins, including those
for scoped fences and some specific RMWs. However, at present we don't
map syncscopes to their SPIR-V equivalents, but rather use the AMDGCN
ones. This ends up pessimising the resulting code as system scope is
used instead of device (agent) or subgroup (wavefront), so we correct
the behaviour, to ensure that we do the right thing during reverse
translation.
|
|
type. (#161231)
Fixes #160497
Fixes #56652
Fixes #116319
Fixes #161196
|
|
Adding a new builtin type for AMDGPU's image descriptor rsrc data type
This requires for https://github.com/llvm/llvm-project/pull/140210
|
|
|
|
While working on vector deleting destructors support
([GH19772](https://github.com/llvm/llvm-project/issues/19772)), I
noticed that MSVC produces different code in scalar deleting destructor
body depending on whether class defined its own operator delete. In
MSABI deleting destructors accept an additional implicit flag parameter
allowing some sort of flexibility. The mismatch I noticed is that
whenever a global operator delete is called, i.e. `::delete`, in the
code produced by MSVC the implicit flag argument has a value that makes
the 3rd bit set, i.e. "5" for scalar deleting destructors "7" for vector
deleting destructors.
Prior to this patch, clang handled `::delete` via calling global
operator delete direct after the destructor call and not calling class
operator delete in scalar deleting destructor body by passing "0" as
implicit flag argument value. This is fine until there is an attempt to
link binaries compiled with clang with binaries compiled with MSVC. The
problem is that in binaries produced by MSVC the callsite of the
destructor won't call global operator delete because it is assumed that
the destructor will do that and a destructor body generated by clang
will never do.
This patch removes call to global operator delete from the callsite and
add additional check of the 3rd bit of the implicit parameter inside of
scalar deleting destructor body.
---------
Co-authored-by: Tom Honermann <tom@honermann.net>
|
|
In
https://github.com/llvm/llvm-project/commit/45ca613c135ea7b5fbc63bff003f20bf20f62081,
whether to mangle names based on calling conventions according to
Microsoft conventions was refactored to a bool in the TargetInfo. Cygwin
targets also require this mangling, but were missed, presumably due to
lack of test coverage of these targets. This commit enables the name
mangling for Cygwin, and also enables test coverage of this mangling on
Cygwin targets.
|
|
Tests exercizing TBAA metadata (both purposefully and not), and
previously generated via UTC, have been regenerated and updated
to version 6.
|
|
Fixes: https://github.com/llvm/llvm-project/issues/67154
{Con, De}structor attributes in Clang only work with integer priorities
(inconsistent with GCC). This commit adds support to these attributes
for template arguments.
Built off of contributions from [abrachet](https://github.com/abrachet)
in [#67376](https://github.com/llvm/llvm-project/pull/67376).
|
|
Update the codegen for the the dynamic_cast to a final class
optimization when pointer authentication is enabled.
|
|
(#155080)
fix: #151716
In #65918, support of incomplete array type is added in
TryReferenceListInitialization. It causes the crash in Constant Expr
Calculation since it only considers the case where it is
ConstantArrayType.
This patch wants to add support for incomplete array type also.
|
|
This implements support for [named
loops](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm) for
C2y.
When parsing a `LabelStmt`, we create the `LabeDecl` early before we parse
the substatement; this label is then passed down to `ParseWhileStatement()`
and friends, which then store it in the loop’s (or switch statement’s) `Scope`;
when we encounter a `break/continue` statement, we perform a lookup for
the label (and error if it doesn’t exist), and then walk the scope stack and
check if there is a scope whose preceding label is the target label, which
identifies the jump target.
The feature is only supported in C2y mode, though a cc1-only option
exists for testing (`-fnamed-loops`), which is mostly intended to try
and make sure that we don’t have to refactor this entire implementation
when/if we start supporting it in C++.
---------
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
|
|
This fixes a regression reported here:
https://github.com/llvm/llvm-project/pull/147835#issuecomment-3225550458
Since this regression was never released, there are no release notes.
|
|
This happens for e.g. arm's float8 types.
|
|
constructors (#154858)
Fix a bug in CodeGen where such variables could cause a compilation
error or be emitted with an undef initializer when the vtable was signed
with address discrimination.
rdar://155696134
|
|
(#152575)
Previously, the alignment of pointer arithmetics was inferred from the
pointee type, losing the alignment information from its operands:
https://github.com/llvm/llvm-project/blob/503c0908c3450d228debd64baecf41df8f58476e/clang/lib/CodeGen/CGExpr.cpp#L1446-L1449
This patch preserves alignment information for pointer arithmetics `P
+/- C`, to match the behavior of identical array subscript `&P[C]`:
https://godbolt.org/z/xx1hfTrx4.
Closes https://github.com/llvm/llvm-project/issues/152330. Although the
motivating case can be fixed by
https://github.com/llvm/llvm-project/pull/145733, the alignment cannot
be recovered without a dominating memory access with larger alignment.
|
|
Fixes a bug on AMDGPU targets where a pointer was stored as address
space 5, but then loaded as address space 0.
Issue found as part of [Kokkos](https://github.com/kokkos/kokkos)
testing, specifically `hip.atomics` (see
[core/unit_test/TestAtomics.hpp](https://github.com/kokkos/kokkos/blob/develop/core/unit_test/TestAtomics.hpp)).
Issue was introduced by commit
[39ec9de7c230](https://github.com/llvm/llvm-project/commit/39ec9de7c230)
- [clang][CodeGen] sret args should always point to the alloca AS, so
use that (https://github.com/llvm/llvm-project/pull/114062).
|
|
directory (#154538)
This patch works towards consolidating all Clang debug-info into the
`clang/test/DebugInfo` directory
(https://discourse.llvm.org/t/clang-test-location-of-clang-debug-info-tests/87958).
Here we move only the `clang/test/CodeGenCXX` tests. I created a `CXX`
subdirectory for now because many of the tests I checked actually did
seem C++-specific. There is probably overlap between the `Generic` and
`CXX` subdirectory, but I haven't gone through and audited them all.
The list of files i came up with is:
1. searched for anything with `*debug-info*` in the filename
2. searched for occurrences of `debug-info-kind` in the tests
There's a couple of tests in `clang/test/CodeGenCXX` that still set
`-debug-info-kind`. They probably don't need to do that, but I'm not
changing that as part of this PR.
|
|
Summary:
It's extremely common to conditionally blend two vectors. Previously
this was done with mask registers, which is what the normal ternary code
generation does when used on a vector. However, since Clang 15 we have
supported boolean vector types in the compiler. These are useful in
general for checking the mask registers, but are currently limited
because they do not map to an LLVM-IR select instruction.
This patch simply relaxes these checks, which are technically forbidden
by
the OpenCL standard. However, general vector support should be able to
handle these. We already support this for Arm SVE types, so this should
be make more consistent with the clang vector type.
|
|
dependent explicit object parameter (#154276)
We have a flag that tracks whether a `CXXThisExpr` refers to a `*this`
capture in a lambda with a dependent explicit object parameter; this is
to mark it and member accesses involving it as dependent because there
is no other way to track that (DREs have a similar flag); when
instantiating the lambda, we need to always rebuild the `CXXThisExpr` to
potentially clear that flag if the explicit object parameter is no
longer dependent.
Fixes #154054.
|
|
Several Clang tests were failing on Cygwin, and were already marked as
requiring !system-windows, unsupported on system-windows, or xfail on
system-windows. Add system-cygwin to lit's llvm.config, and use it in
such tests in addition to system-windows.
|
|
Now that #149310 has restricted lifetime intrinsics to only work on
allocas, we can also drop the explicit size argument. Instead, the size
is implied by the alloca.
This removes the ability to only mark a prefix of an alloca alive/dead.
We never used that capability, so we should remove the need to handle
that possibility everywhere (though many key places, including stack
coloring, did not actually respect this).
|
|
This corrects the codegen for the final class optimization to
correct handle the case where there is no path to perform the
cast, and also corrects the codegen to handle ptrauth protected
vtable pointers.
As part of this fix we separate out the path computation as
that makes it easier to reason about the failure code paths
and more importantly means we can know what the type of the
this object is during the cast.
The allows us to use the GetVTablePointer interface which
correctly performs the authentication operations required when
pointer authentication is enabled. This still leaves incorrect
authentication behavior in the multiple inheritance case but
currently the optimization is disabled entirely if pointer
authentication is enabled.
Fixes #137518
|
|
When casting a 0 to a pointer type, the IsNullPtr flag was always set to
false, leading to weird results like a pointer with value 0 that isn't a
null pointer.
This caused
```c++
struct B { const int *p;};
template<B> void f() {}
template void f<B{nullptr}>();
template void f<B{fold(reinterpret_cast<int*>(0))}>();
```
to be valid code, since nullptr and (int*)0 aren't equal. This seems
weird and GCC doesn't behave like this.
|
|
The codegen for the final class dynamic_cast optimization fails to
consider pointer authentication. This change resolves this be simply
disabling the optimization when pointer authentication enabled.
|
|
`gfx1250` bring-up omitted updating the `amdgcnspirv` feature list, this
fixes that oversight.
|
|
(#151684)
On COFF platform, d1b0cbff806b50d399826e79b9a53e4726c21302 generates a
debug info linked with VTable regardless definition is present or not.
If that VTable ends up implicitly dllimported from another DLL, ld.bfd
produces a runtime pseudo relocation for it (LLD doesn't, since
d17db6066d2524856fab493dd894f8396e896bc7). If the debug section is
stripped, the runtime pseudo relocation points to memory space outside
of the module, causing an access violation.
At this moment, we simply disable VTable debug info on COFF platform to
avoid this problem.
|
