ExternalASTMerger has hitherto relied on being able to look up
any Decl through its named DeclContext chain. This works for
many cases, but causes problems for function-local structs,
which cannot be looked up in their containing FunctionDecl. An
example case is
void f() {
{ struct S { int a; }; }
{ struct S { bool b; }; }
}
It is not possible to lookup either of the two Ses individually
(or even to provide enough information to disambiguate) after
parsing is over; and there is typically no need to, since they
are invisible to the outside world.
However, ExternalASTMerger needs to be able to complete either
S on demand. This led to an XFAIL on test/Import/local-struct,
which this patch removes. The way the patch works is:
It defines a new data structure, ExternalASTMerger::OriginMap,
which clients are expected to maintain (default-constructing
if the origin does not have an ExternalASTMerger servicing it)
As DeclContexts are imported, if they cannot be looked up by
name they are placed in the OriginMap. This allows
ExternalASTMerger to complete them later if necessary.
As DeclContexts are imported from an origin that already has
its own OriginMap, the origins are forwarded – but only for
those DeclContexts that are actually used. This keeps the
amount of stored data minimal.
The patch also applies several improvements from review:
- Thoroughly documents the interface to ExternalASTMerger;
- Adds optional logging to help track what's going on; and
- Cleans up a bunch of braces and dangling elses.
Differential Revision: https://reviews.llvm.org/D38208
llvm-svn: 314336
AuxTriple is not set if host and device share a toolchain. Also,
removing an argument modifies the DAL which needs to be returned
for future use.
(Move tests back to offload-openmp.c as they are not related to GPUs.)
Differential Revision: https://reviews.llvm.org/D38258
llvm-svn: 314329
Parsing the argument after -Xopenmp-target allocates memory that needs
to be freed. Associate it with the final DerivedArgList after we know
which one will be used.
Differential Revision: https://reviews.llvm.org/D38257
llvm-svn: 314328
Added missing addrspacecast case in alignment computation
logic of pointer type emission in IR generation.
Differential Revision: https://reviews.llvm.org/D37804
llvm-svn: 314304
Summary: Test for checking if the mapping is performed correctly. This is a test initially included in Patch https://reviews.llvm.org/D29905
Reviewers: Hahnfeld, carlo.bertolli, caomhin, ABataev
Reviewed By: Hahnfeld
Subscribers: tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D38040
llvm-svn: 314303
Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized.
supersedes D33277, D35775
Corrsponds with D37412, D37413
llvm-svn: 314300
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
middle-end.
This change emits the section information for all targets.
Patch By: Elizabeth Andrews
Differential Revision:https://reviews.llvm.org/D36487
llvm-svn: 314262
It was brought up in response to my last implementation for
this struct-as-interface features that at least 1 header in
the MS SDK uses "extern C++" around an IUnknown declaration.
The previous implementation demanded that this type exist
in the TranslationUnit DeclContext. This small change simply
also allows in the situation where we're extern "C++".
llvm-svn: 314235
When selecting constructors for initializing an object of type T from a single
expression of class type U, also consider conversion functions of U that
convert to T (rather than modeling such conversions as calling a conversion
function and then calling a constructor).
This approach is proposed as the resolution for the defect, and is also already
implemented by GCC.
llvm-svn: 314231
Discovered that 'nothrow' (which is supposed to be an alias for noexcept)
was not warning with a throw inside of it. This patch corrects the behavior
previously created to add 'nothrow' to this list.
Differential Revision: https://reviews.llvm.org/D38203
llvm-svn: 314229
Summary: Test for checking if the mapping is performed correctly. This is a test initially included in Patch https://reviews.llvm.org/D29905
Reviewers: Hahnfeld, carlo.bertolli, caomhin
Reviewed By: Hahnfeld
Subscribers: tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D38040
llvm-svn: 314228
The `__va_start` intrinsic for Windows ARM does not account for const
correctness when performing a check. All local qualifiers are ignored
when validating the invocation. This was exposed by building the swift
stdlib against the Windows 10586 SDK for ARM. Simply expand out the
check for the two parameters and ignore the qualifiers for the check.
llvm-svn: 314226
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314217
-mbranch-likely and -mno-branch-likely are used in some build systems for
some MIPS targets. Accept these options but ignore them as they are an
(de)optimiztion hint, and that branch likely instructions were deprecated
but not removed from MIPS32 and MIPS64 ISAs.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D38168
llvm-svn: 314213
Summary: Test for checking if the mapping is performed correctly. This is a test initially included in Patch https://reviews.llvm.org/D29905
Reviewers: Hahnfeld, carlo.bertolli, caomhin
Reviewed By: Hahnfeld
Subscribers: tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D38040
llvm-svn: 314210
This patch fixes clang to decorate reference accesses as pointers
and not as "omnipotent chars".
Differential Revision: https://reviews.llvm.org/D38074
llvm-svn: 314209
directives.
If the variable is used in the target-based region but is not found in
any private|mapping clause, then generate implicit firstprivate|map
clauses for these implicitly mapped variables.
llvm-svn: 314205
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314188
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314177
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
Summary: Enable the -nocudalib flag for the OpenMP device offloading toolchain as well. Currently it can only be used for the CUDA toolchain.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37913
llvm-svn: 314164
Summary: When composing the output file name, the path to the file is being dropped. The full path is required.
Reviewers: Hahnfeld, ABataev, caomhin, carlo.bertolli, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37912
llvm-svn: 314156
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314150
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 314145
Clang regression tests that depend on the optimizer can break
when there are changes to LLVM...as in:
https://reviews.llvm.org/rL314117
llvm-svn: 314144
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
Sean Callanan