Summary:
This distinguishes between -fpic and -fPIC now, with the additions in LLVM for
PIC level support.
Test Plan: No regressions
Reviewers: echristo, rafael
Reviewed By: rafael
Subscribers: rnk, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D5400
llvm-svn: 222227
Currently this function would return nothing for functions or globals that
haven't seen a definition yet. Make it return a forward declaration that will
get RAUWed with the definition if one is seen at a later point. The strategy
used to implement this is similar to what's done for types: the forward
declarations are stored in a vector and post processed upon finilization to
perform the required RAUWs.
For now the only user of getDeclarationOrDefinition() is EmitUsingDecl(), thus
this patch allows to emit correct imported declarations even in the absence of
an actual definition of the imported entity.
(Another user will be the debug info generation for argument default values
that I need to resurect).
Differential Revision: http://reviews.llvm.org/D6173
llvm-svn: 222220
We include unused functions and methods in -fcoverage-mapping so that
we can differentiate between uninstrumented and unused. This can cause
problems for uninstantiated templates though, since they may involve
an incomplete type that can't be mangled. This shows up in things like
libc++'s <unordered_map> and makes coverage unusable.
Avoid the issue by skipping uninstantiated methods of a templated
class.
llvm-svn: 222204
When targeting Windows itanium (a MSVC environment), use itanium style
exceptions rather than SEH. Existing test cases already test this code path.
Applying this change ensures that tests wont break due to a parallel change in
LLVM (to correctly report isMSVCEnvironment).
llvm-svn: 222179
used inside blocks. It fixes a crash in naming code
for __func__ etc. when used in a block declared globally.
It also brings back old naming convention for
predefined expression which was broken. rdar://18961148
llvm-svn: 222065
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
This patch enables the vec_vsx_ld and vec_vsx_st intrinsics for
PowerPC, which provide programmer access to the lxvd2x, lxvw4x,
stxvd2x, and stxvw4x instructions.
New code in altivec.h defines these in terms of new builtins, which
are themselves defined in BuiltinsPPC.def. The builtins are converted
to LLVM intrinsics in CGBuiltin.cpp. Additional code is added to
builtins-ppc-vsx.c to verify the correct generation of the intrinsics.
Note that I moved the other VSX builtins so all VSX builtins will be
alphabetical in their own section in BuiltinsPPC.def.
There is a companion patch for LLVM.
llvm-svn: 221768
Summary: If we've added poisoned paddings to a type do not emit memcpy for operator=.
Test Plan: regression tests.
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6160
llvm-svn: 221739
Summary:
This change makes the asan-coverge (formerly -mllvm -asan-coverge)
accessible via a clang flag.
Companion patch to LLVM is http://reviews.llvm.org/D6152
Test Plan: regression tests, chromium
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6153
llvm-svn: 221719
Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to be true),
together with sanitizer kinds these checks are for. This would allow
to split one call into UBSan runtime into several calls in case
different sanitizer kinds would have different recoverability
settings.
Tests should be fixed accordingly, I'm working on it.
Test Plan: regression test suite.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6219
llvm-svn: 221716
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
llvm-svn: 221704
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
llvm-svn: 221663
Get rid of ugly SanitizerOptions class thrust into LangOptions:
* Make SanitizeAddressFieldPadding a regular language option,
and rely on default behavior to initialize/reset it.
* Make SanitizerBlacklistFile a regular member LangOptions.
* Introduce the helper class "SanitizerSet" to represent the
set of enabled sanitizers and make it a member of LangOptions.
It is exactly the entity we want to cache and modify in CodeGenFunction,
for instance. We'd also be able to reuse SanitizerSet in
CodeGenOptions for storing the set of recoverable sanitizers,
and in the Driver to represent the set of sanitizers
turned on/off by the commandline flags.
No functionality change.
llvm-svn: 221653
Make sure CodeGenFunction::EmitCheck() knows which sanitizer
it emits check for. Make CheckRecoverableKind enum an
implementation detail and move it away from header.
Currently CheckRecoverableKind is determined by the type of
sanitizer ("unreachable" and "return" are unrecoverable,
"vptr" is always-recoverable, all the rest are recoverable).
This will change in future if we allow to specify which sanitizers
are recoverable, and which are not by -fsanitize-recover= flag.
No functionality change.
llvm-svn: 221635
Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being
flattened (e.g. [2 x float] rather than "float, float") for various weird ABI
reasons. However, this isn't the case for anything else; further, we know at
the ABIArgInfo::getDirect callsites whether this flattening is allowed.
So, we can get more unified ARM code, with a simpler Clang, by just using that
knowledge directly.
llvm-svn: 221559
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
We would blindly assume that RTTI data should have the same linkage as
the vtable because we didn't think the RTTI data was external. This
oversight stemmed because we didn't take dllimport into account.
This fixes PR21512.
llvm-svn: 221511
Custom targets in cmake cannot be exported, and this dependency is only
needed in the combined build to ensure that Intrinsics.gen is created
before compiling CodeGen. In the standalone, all of LLVM is build first.
llvm-svn: 221391
When we are generating the global initializer functions, we call
CGDebugInfo::EmitFunctionStart() with a valid decl which is describing
the initialized global variable. Do not update the DeclCache with this
key as it will overwrite the the cached variable DIGlobalVariable with
the newly created artificial DISubprogram.
One could wonder if we should put artificial subprograms in the DIE tree
at all (there are vaild uses for them carrying line information though).
llvm-svn: 221385
mingw64's headers implement fabs by calling __builtin_fabs, so using the
library call results in an infinite loop. If the backend legalizes
@llvm.fabs as a call to fabs later, things should work out, as the crt
provides a definition.
llvm-svn: 221206
Local variables are not initialized, and every target has
been (incorrectly) ignoring the unnecessary request for
zero initialization.
llvm-svn: 221162
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
llvm-svn: 221154
It says there is a narrowing conversion when we assign it to an unsigned
3 bit bitfield.
Also, use unsigned instead of size_t for the Size field of the struct in
question. Otherwise they won't run together in MSVC or clang-cl.
llvm-svn: 221019
The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates. Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.
This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D6063
llvm-svn: 221006
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.
Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5996
llvm-svn: 220993
Summary:
When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.
Test Plan: added a test
Reviewers: rsmith, rnk, rafael
Reviewed By: rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6038
llvm-svn: 220986
Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.
Also make the record expansion code work in the presence of non-virtual
bases.
Reviewed By: uweigand, asl
Differential Revision: http://reviews.llvm.org/D6045
llvm-svn: 220972
David Blaikie