| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 240452
|
| |
|
|
|
|
|
|
|
|
| |
Regular function calls (such as to cabs()) run into the same problem
with handling dependent exprs, not just builtins with custom type
checking.
Fixes PR23775.
llvm-svn: 240443
|
| |
|
|
|
|
|
|
|
| |
checking those calls when not in C++ mode, since those code paths can't
handle dependent exprs.
Fixes PR23740.
llvm-svn: 240441
|
| |
|
|
| |
llvm-svn: 240434
|
| |
|
|
|
|
|
| |
Any extra features from -fmodule-feature are part of the module hash and
need to get validated on load. Also print them with -module-file-info.
llvm-svn: 240433
|
| |
|
|
| |
llvm-svn: 240432
|
| |
|
|
|
|
| |
Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0).
llvm-svn: 240409
|
| |
|
|
| |
llvm-svn: 240406
|
| |
|
|
|
|
| |
to the caller instead of hiding it in emitReport. NFC.
llvm-svn: 240400
|
| |
|
|
|
| |
FIXME: Should "Level" be unsigned?
llvm-svn: 240391
|
| |
|
|
|
|
|
|
| |
VXABI' :
not all control paths return a value.
llvm-svn: 240389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Member pointers in the MS ABI are made complicated due to the following:
- Virtual methods in the most derived class (MDC) might live in a
vftable in a virtual base.
- There are four different representations of member pointer: single
inheritance, multiple inheritance, virtual inheritance and the "most
general" representation.
- Bases might have a *more* general representation than classes which
derived from them, a most surprising result.
We believed that we could treat all member pointers as-if they were a
degenerate case of the multiple inheritance model. This fell apart once
we realized that implementing standard member pointers using this ABI
requires referencing members with a non-zero vbindex.
On a bright note, all but the virtual inheritance model operate rather
similarly. The virtual inheritance member pointer representation
awkwardly requires a virtual base adjustment in order to refer to
entities in the MDC.
However, the first virtual base might be quite far from the start of the
virtual base. This means that we must add a negative non-virtual
displacement.
However, things get even more complicated. The most general
representation interprets vbindex zero differently from the virtual
inheritance model: it doesn't reference the vbtable at all.
It turns out that this complexity can increase for quite some time:
consider a derived to base conversion from the most general model to the
multiple inheritance model...
To manage this complexity we introduce a concept of "normalized" member
pointer which allows us to treat all three models as the most general
model. Then we try to figure out how to map this generalized member
pointer onto the destination member pointer model. I've done my best to
furnish the code with comments explaining why each adjustment is
performed.
This fixes PR23878.
llvm-svn: 240384
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI has very complicated member pointers. Don't attempt to
synthesize the final member pointer ab ovo usque ad mala in one go.
Instead, start with a member pointer which points to the declaration in
question as-if it's decl context was the target class. Then, utilize
our conversion logical to convert it to the target type.
This allows us to simplify how we think about member pointers because we
don't need to consider non-zero nv adjustments before we even generate
the member pointer. Furthermore, it gives our adjustment logic more
exposure by utilizing it in a common path.
llvm-svn: 240383
|
| |
|
|
| |
llvm-svn: 240382
|
| |
|
|
|
|
|
| |
Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy.
Differential Revision: http://reviews.llvm.org/D9550
llvm-svn: 240377
|
| |
|
|
|
|
| |
(Caused by r240370)
llvm-svn: 240376
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10612
llvm-svn: 240370
|
| |
|
|
| |
llvm-svn: 240353
|
| |
|
|
|
|
|
| |
file in the loaded module maps and one of them is from the current module,
that's the right match.
llvm-svn: 240350
|
| |
|
|
|
|
| |
by pointer) from ParseArgs
llvm-svn: 240349
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As specified in the SysV AVX512 ABI drafts. It follows the same scheme
as AVX2:
Arguments of type __m512 are split into eight eightbyte chunks.
The least significant one belongs to class SSE and all the others
to class SSEUP.
This also means we change the OpenMP SIMD default alignment on AVX512.
Based on r240337.
Differential Revision: http://reviews.llvm.org/D9894
llvm-svn: 240338
|
| |
|
|
|
|
|
| |
Follow-up to r237989: expressing the AVX level as an enum makes it
simple to extend it with AVX512.
llvm-svn: 240337
|
| |
|
|
|
|
|
|
|
|
|
|
| |
redefinitions of internal-linkage symbols that are not visible.
Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)
llvm-svn: 240335
|
| |
|
|
| |
llvm-svn: 240328
|
| |
|
|
| |
llvm-svn: 240313
|
| |
|
|
| |
llvm-svn: 240297
|
| |
|
|
| |
llvm-svn: 240279
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
| |
|
|
| |
llvm-svn: 240252
|
| |
|
|
|
|
|
|
|
|
| |
The same pattern was repeated a few times. Create a trivial helper method to
map the Type Specifier to an ID for the diagnostic. Flip the selection order on
one of the diagnostic messages to get the same ordering across all of the
messages. This makes the emission of the diagnostic slightly more legible by
changing the cascading ternary into a switch in a function. NFC.
llvm-svn: 240251
|
| |
|
|
|
|
|
|
|
|
| |
This is a better approach to fixing the undefined behaviour I tried to
fix in r240228. This data doesn't necessarily have suitable alignment
for uint64_t, so use unaligned_uint64_t instead.
This fixes 225 test failures when clang is built with ubsan.
llvm-svn: 240247
|
| |
|
|
|
|
|
|
|
| |
We can do this better by changing the type to unaligned_uint64_t and
paying the cost on use instead of up front.
This reverts r240228
llvm-svn: 240246
|
| |
|
|
|
|
| |
Convert a hand rolled for loop into an explicit for loop. NFC.
llvm-svn: 240245
|
| |
|
|
|
|
|
|
|
|
|
| |
Testcase provided, in the PR, by Christian Shelton and
reduced by David Majnemer.
PR: 23584
Differential Revision: http://reviews.llvm.org/D10508
Reviewed by: rnk
llvm-svn: 240242
|
| |
|
|
| |
llvm-svn: 240237
|
| |
|
|
|
|
|
|
|
|
| |
We interpret Blob as an array of uint64_t here, but there's no reason
to think that it has suitable alignment. Instead, read the data in in
an alignment-safe way and store it in a std::vector.
This fixes 225 test failures when clang is built with ubsan.
llvm-svn: 240228
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.
The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.
rdar://problem/20091852
llvm-svn: 240225
|
| |
|
|
|
|
|
| |
We already test for PrioritizedCXXGlobalInits being non-empty
and process it so it makes sense to clear it only in that if.
llvm-svn: 240220
|
| |
|
|
| |
llvm-svn: 240209
|
| |
|
|
|
|
| |
all modules even if we've already found a definition that's not visible.
llvm-svn: 240204
|
| |
|
|
| |
llvm-svn: 240200
|
| |
|
|
| |
llvm-svn: 240199
|
| |
|
|
| |
llvm-svn: 240196
|
| |
|
|
| |
llvm-svn: 240190
|
| |
|
|
|
|
|
|
|
|
| |
These usually apply to the return type. At one point this was necessary to
get some of them to apply to the entire block, but it appears that's working
anyway (see block-return.c).
rdar://problem/20468034
llvm-svn: 240189
|
| |
|
|
|
|
|
|
|
|
| |
...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self".
rdar://problem/19924646
llvm-svn: 240188
|
| |
|
|
|
|
| |
rdar://problem/21134250
llvm-svn: 240187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
That is,
void cf2(CFTypeRef * __nullable p CF_RETURNS_NOT_RETAINED);
is equivalent to
void cf2(CFTypeRef __nullable * __nullable p CF_RETURNS_NOT_RETAINED);
More rdar://problem/18742441
llvm-svn: 240186
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.
This feature can be tested for using __has_feature(cf_returns_on_parameters).
This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
refer to "property" instead of "method" in the error message.
rdar://problem/18742441
llvm-svn: 240185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triple.
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.
llvm-svn: 240179
|