Trying to evaluate a GEP would assert with
"Ty == cast<PointerType>(C->getType()->getScalarType())->getElementType()"
because the type of the pointer we would evaluate the GEP argument to
would be a different type than the GEP was expecting. We should treat
pointer stripping as a bitcast.
The test adds a redundant GEP that would crash due to type mismatch.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D100970
An empty macro that expands to just `... else ;` can get
warnings from some compilers (e.g. GCC's -Wempty-body).
Reviewed By: cryptoad, vitalybuka
Differential Revision: https://reviews.llvm.org/D100693
`RichManglingContext::FromCxxMethodName` allocates a m_cxx_method_parser, but never deletes it.
This fixes a `-DLLVM_USE_SANITIZER=Leaks` failure.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D100795
Discovered during attributor testing comparing stats with
and without the attributor. Willreturn should not be inferred
for nonexact definitions.
Differential Revision: https://reviews.llvm.org/D100988
If these sizes do not match, asan will not work as expected. Previously, we added compile-time checks for non-iOS platforms. We check at run time for iOS because we get the max VM size from the kernel at run time.
rdar://76477969
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D100784
Fix for PR49984
This was discovered during Attributor testing.
Memset was always created with alignment of 1
and in case when strncpy alignment was changed
it triggered an assertion in the AttrBuilder.
Memset will now be created with appropriate alignment.
Differential Revision: https://reviews.llvm.org/D100875
This will prevent fusion that spains all dims and generates
(d0, d1, ...) -> () reshape that isn't legal
Differential Revision: https://reviews.llvm.org/D100805
PR50049 demonstrated an infinite loop between OR(SHUFFLE,SHUFFLE) <-> BLEND(SHUFFLE,SHUFFLE) patterns.
The UNDEF elements were allowing a combined shuffle mask to be widened which lost the undef element, resulting us needing to use the BLEND pattern (as the undef element would need to be zero for the OR pattern). But then bitcast folds would re-expose the undef element allowing us to use OR again.....
Add initial tests for reading register sets from core dumps. This
includes a C++ program to write registers and dump core, resulting core
dumps for Linux, FreeBSD and NetBSD, and the tests to verify them.
The tests are split into generic part, verifying user-specified register
values, and coredump-specific tests that verify memory addresses that
differ for every dump.
At this moment, all platforms support GPRs and FPRs up to XMM for amd64
target. The i386 target does not work on NetBSD at all, and is missing
FPRs entirely on FreeBSD.
Differential Revision: https://reviews.llvm.org/D91963
This load command records a range spanning from the end of the load
commands to the end of the `__TEXT` segment. Presumably the kernel will encrypt
all this data.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D100973
The implicitly generated mappings for allocation/deallocation in mappers
runtime should be mapped as implicit, also no need to clear member_of
flag to avoid ref counter increment. Also, the ref counter should not be
incremented for the very first element that comes from the mapper
function.
Differential Revision: https://reviews.llvm.org/D100673
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D99873.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D100073
external.c defines stub functions that are never used because of how
Polly uses PPCG. Unfortunately, they are declared as functions without
return values or parameters which does not match their declarations.
Since they are never called, this was usually not a problem, but an LTO
build gets confused with differently declared functions, or in case of
pet_options_args, a global variable declaration that is defined as a
function
Resolve by including the declaring headers in external.c which forces
the declaration and definition to match at compile-time.
This fixes llvm.org/50021
Simplify the test code, and drive-by also test that these algorithms
return the right iterator as their return value.
Differential Revision: https://reviews.llvm.org/D100876
The test had a race that could cause two threads to end up with the same
"thread local" value. I believe this would not cause the test to fail,
but it could cause it to succeed even when the functionality is broken.
The new implementation removes this uncertainty, and removes a lot of
cruft left over from the time this test was written using pthreads.
Let it work on a very small kernels only. Measurements showed
the performance benefit is not worth the compile time.
Differential Revision: https://reviews.llvm.org/D100904
`asserts` is a pseudo keyword in TypeScript used in return types.
Wrapping after it triggers automatic semicolon insertion, which
breaks the code semantics/syntax.
`asserts` is different from other pseudo keywords in that it is
specific to TS and only carries meaning in a very specific location.
Thus introducing a token type is probably overkill.
Differential Revision: https://reviews.llvm.org/D100953
- Previously, https://reviews.llvm.org/D72680 introduced a new attribute called `AllowSymbolAtNameStart` (in relation to the MAsmParser changes) in `MCAsmInfo.h` which (according to the comment in the header) allows the following behaviour:
```
/// This is true if the assembler allows $ @ ? characters at the start of
/// symbol names. Defaults to false.
```
- However, the usage of this field in AsmLexer.cpp doesn't seem completely accurate* for a couple of reasons.
```
default:
if (MAI.doesAllowSymbolAtNameStart()) {
// Handle Microsoft-style identifier: [a-zA-Z_$.@?][a-zA-Z0-9_$.@#?]*
if (!isDigit(CurChar) &&
isIdentifierChar(CurChar, MAI.doesAllowAtInName(),
AllowHashInIdentifier))
return LexIdentifier();
}
```
1. The Dollar and At tokens, when occurring at the start of the string, are treated as separate tokens (AsmToken::Dollar and AsmToken::At respectively) and not lexed as an Identifier.
2. I'm not too sure why `MAI.doesAllowAtInName()` is used when `AllowAtInIdentifier` could be used. For X86 platforms, afaict, this shouldn't be an issue, since the `CommentString` attribute isn't "@". (alternatively the call to the setter can be set anywhere else as needed). The `AllowAtInName` does have an additional important meaning, but in the context of AsmLexer, shouldn't mean anything different compared to `AllowAtInIdentifier`
My proposal is the following:
- Introduce 3 new fields called `AllowQuestionTokenAtStartOfString`, `AllowDollarTokenAtStartOfString` and `AllowAtTokenAtStartOfString` in MCAsmInfo.h which will encapsulate the previously documented behaviour of "allowing $, @, ? characters at the start of symbol names")
- Introduce these fields where "$", "@" are lexed, and treat them as identifiers depending on whether `Allow[Dollar|At]TokenAtStartOfString` is set.
- For the sole case of "?", append it to the existing logic for treating a "default" token as an Identifier.
z/OS (HLASM) will also make use of some of these fields in follow up patches.
completely accurate* - This was based on the comments and the intended behaviour the code. I might have completely misinterpreted it, and if that is the case my sincere apologies. We can close this patch if necessary, if there are no changes to be made :)
Depends on https://reviews.llvm.org/D99374
Reviewed By: Jonathan.Crowther
Differential Revision: https://reviews.llvm.org/D99889
Break up the dependency between SCF ops and substituteMin helper and make a
more generic version of AffineMinSCFCanonicalization. This reduce dependencies
between linalg and SCF and will allow the logic to be used with other kind of
ops. (Like ID ops).
Differential Revision: https://reviews.llvm.org/D100321
CommandLine.h is indirectly included in ~50% of TUs when building
clang, and VirtualFileSystem.h is large.
(Already remarked by jhenderson on D70769.)
No behavior change.
Differential Revision: https://reviews.llvm.org/D100957
Clang only defines __VFP_FP__ when the FPU is enabled. However, gcc
defines it unconditionally.
This patch aligns Clang with gcc.
Reviewed By: peter.smith, rengolin
Differential Revision: https://reviews.llvm.org/D100372
Arthur Eubanks