VSX makes the "vector long long" and "vector double" types available.
This patch enables the vec_perm interface for these types. The same
builtin is generated regardless of the specified type, so no
additional work or testing is needed in the back end. Tests are added
to ensure this builtin is generated by the front end.
llvm-svn: 221988
This patch adds builtin support for xvdivdp and xvdivsp, along with a
new test case. The builtins are accessed using vec_div in altivec.h.
Builtins are listed (mostly) alphabetically there, so inserting these
changed the line numbers for deprecation warnings tested in
test/Headers/altivec-intrin.c.
There is a companion patch for LLVM.
llvm-svn: 221984
Currently there is a bug in processing of global variables used as loop control variables in 'omp for/simd' constructs: these globals must be captured as private variables, but currently they are nor. This is a temporary bug fix for this problem until the correct solution is prepared. If a global var used as lcv without explicit mark as a private/linear/lastprivate the error message is emitted.
llvm-svn: 221970
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
a member named 'swap' and then expect unqualified lookup for the name 'swap' in
its exception specification to find anything else.
Without delay-parsed exception specifications, this was ill-formed (NDR) by
[basic.scope.class]p1, rule 2. With delay-parsed exception specifications, the
call to 'swap' unambiguously finds the function being declared, which then
fails because the arguments don't work for that function.
llvm-svn: 221955
This change removes libclang_rt.profile-pic-<arch>.a version of
profile runtime. Instead, it's sufficient to always build
libclang_rt.profile-<arch>.a with -fPIC, as it can be linked into
both executables and shared objects.
llvm-svn: 221952
of new warning for deprecated method call for receiver
of type 'id'. This addresses rdar://18960378 where
unintended warnings being issued.
llvm-svn: 221933
The Autoconf build already does this, but it was never ported to
CMake. The host linker version affects the flags that Clang pass
to the linker, notably whether it passes -demangle or not.
http://reviews.llvm.org/D6239
llvm-svn: 221844
expansion into a parameter pack; we know that we're still filling in that
parameter's arguments. Previously, if we hit this case for an alias template,
we'd try to substitute using non-canonical template arguments.
llvm-svn: 221832
Summary:
Consider the following nifty 1 liner: (0 ? csqrtl(2.0f) : sqrtl(2.0f)). One can easily obtain such code from e.g. tgmath. Right now it produces an assertion because we fail to do the promotion real => _Complex real.
The case was properly handled previously (old handleOtherComplexFloatConversion routine), but was forgotten in the current version. This seems to be about fallout from r219557
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6217
llvm-svn: 221821
The check for unnamed members was intended to skip unnamed bitfields,
but it ended up skipping unnamed structs. This lead to an assertion in
IRGen.
llvm-svn: 221818
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
Without this, -Wunused-local-typedef would incorrectly warn on the two typedefs
in this program:
void foo() {
struct A {};
struct B : public A {
typedef A INHERITED;
B() : INHERITED() {}
typedef B SELF;
B(int) : SELF() {}
};
}
llvm-svn: 221765
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
This is a re-commit of r219977:
r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2.
(That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of
'this' within a template.)
r219977 was a re-commit of r217995, r218011, and r218053:
r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC.
(Incorrect overload resolution in the presence of using-declarations.)
It was re-committed in r219977 with a workaround for the MSVC rejects-valid.
r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of
unbraced range-based for loop).
llvm-svn: 221750
penultimate parameter of a template parameter list, where the last parameter is
itself a pack, and build a bogus empty final pack argument.
llvm-svn: 221748
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
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
(patch reapplied after lldb issue was fixed in r221660).
llvm-svn: 221691
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
report the 'init*' invocation as non-dynamic via clang_Cursor_isDynamicCall.
Of course it is dynamic at runtime, but for purposes of indexing we can treat as an invocation to ClassName's init*.
Addresses rdar://18916871.
llvm-svn: 221641
is enabled. Unlike system headers, we want to be more careful about
modifications to user headers, because it's still easy to edit a header
while you're building.
llvm-svn: 221634
Darwin's "-arch arm64" option implies full Cyclone CPU, for both architectural
and tuning purposes. So if neither of the explicit options have been given,
forward that on to the proper invocation.
rdar://problem/18906227
llvm-svn: 221631
This allows 'namespace A::B { ... }' as a shorthand for 'namespace A {
namespace B { ... } }'. We already supported this correctly for error recovery;
promote that support to a full implementation.
This is not the right implementation: we do not maintain source fidelity
because we desugar the nested namespace definition in the parser. This is
tricky to avoid, since the definition genuinely does inject one named
entity per level in the namespace name.
llvm-svn: 221574
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
We may need to verify the signature on subsequent imports as well, just
like we verify the size/modtime:
@import A;
@import B; // imports A
@import C; // imports A
llvm-svn: 221569
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
If clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by -ccc-install-dir. This causes several regression tests to fail as they will be using an unexpected path. Adding the switch --gcc-toolchain="" in each test command is not enough as the hexagon toolchain implementation in the driver is not evaluating this argument. This commit modifies the hexagon toolchain to take the --gcc-toolchain="" argument into account when deciding the toolchain path, similarly to what is already done for other targets toolchains. Additionally, the faulty regression tests are modified in order to --gcc-toolchain="" be passed to the commands.
llvm-svn: 221535
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
This patch simplifies how default target features are set for AMD bdver2
and bdver1. In particular, method 'getDefaultFeatures' now implements a
fallthrough from case 'CK_BDVER2' to case 'CK_BDVER1'.
That is because 'bdver2' has the same features available in bdver1 plus
BMI, FMA, F16C and TBM.
This patch also adds missing checks for predefined macros in test
predefined-arch-macros.c. In the case of BTVER2, the test now also checks
for F16C, BMI and PCLMUL. In the case of BDVER3 and BDVER4, the test now
also checks for the presence of FSGSBASE.
Differential Revision: http://reviews.llvm.org/D6134
llvm-svn: 221449
According to C++ standard if an exception-specification is specified in an explicit instantiation directive, it shall be compatible with the exception-specifications of other declarations of that function. This patch adds checks for this.
Differential Revision: http://reviews.llvm.org/D5822
llvm-svn: 221448
This is to accept "NA" in place of vesion number for availability
attribute. Used on introduced=NA to mean unavailable
and deprecated=NA to mean nothing (not deprecated).
rdar://18804883
llvm-svn: 221417
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
John McCall, please review post-commit.
llvm-svn: 221404
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
This DefaultIgnore warning under -Wincomplete-module was firing on
any module map files that happened to be parsed (it's only supposed to
fire on headers), and it has been superceded by
-Wnon-modular-include-in-module anyway.
For compatibility, I rewired -Wincomplete-module to imply
-Wnon-modular-include-in-module.
llvm-svn: 221357
The command line options are specified in a space-separated list that is an
argument to -dwarf-debug-flags, so that breaks if there are spaces in the
options. This feature came from Apple's internal version of GCC, so I went back
to check how llvm-gcc handled this and matched that behavior.
rdar://problem/18775420
llvm-svn: 221309
Change the LC_ID_DYLIB of ASan's dynamic libraries on OS X to be set to "@rpath/libclang_rt.asan_osx_dynamic.dylib" and similarly for iossim. Clang driver then sets the "-rpath" to be the real path to where clang currently has the dylib (because clang uses the relative path to its current executable). This means if you move the compiler or install the binary release, -fsanitize=address will link to the proper library.
Reviewed at http://reviews.llvm.org/D6018
llvm-svn: 221279
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
Now we don't warn on this code:
void __stdcall f(void);
void __stdcall f();
My previous commit regressed this functionality because I didn't update
the relevant test case which used a definition.
llvm-svn: 221188
We already have a warning on the call sites of code like this:
void f() { }
void g() { f(1, 2, 3); }
t.c:2:21: warning: too many arguments in call to 'f'
We can limit ourselves to diagnosing unprototyped forward declarations
of f to cut down on noise.
llvm-svn: 221184
parameters with nonnull attribute when comparison is always
true/false. Patch causes false positive when parameter is
modified in the function.
llvm-svn: 221163
Local variables are not initialized, and every target has
been (incorrectly) ignoring the unnecessary request for
zero initialization.
llvm-svn: 221162
Trying to import or export such classes doesn't make sense, and Clang
would assert trying to export vtables for them.
This is consistent with how we treat functions with internal linkage,
but it is stricter than MSVC so we may have to back down if it breaks
real code.
llvm-svn: 221160
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
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
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
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
Instead of manually maintaining a flag indicating whether we're about to print
out the last child of the parent node (to determine whether we print "`" or
"|"), capture a callable to print that child and defer printing it until we
either see a next child or finish the parent.
No functionality change intended.
llvm-svn: 220930
The Windows NT SDK uses __readfsdword and declares it as a compiler provided
builtin (#pragma intrinsic(__readfsword). Because intrin.h is not referenced
by winnt.h, it is not possible to provide an out-of-line definition for the
intrinsic. Provide a proper compiler builtin definition.
llvm-svn: 220859
Following the NVVM IR specifications, arguments of aggregate type should be
passed on the stack without splitting (byval).
http://reviews.llvm.org/D6020
Patch by Jacques Pienaar.
llvm-svn: 220854
As discussed in bug 21398, PowerPC ABI code needs to consider C++ base
classes when classifying a class as homogeneous aggregate (or not) for
ABI purposes.
llvm-svn: 220852
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
llvm-svn: 220850
but MSABI was never defined in the test. It seems we are erroring
on code that we should be accepting when compiling for MSVC compatibility.
This should make the test less confusing until PR21406 is fixed.
llvm-svn: 220825
explicitly using the resulting .pcm file. Unlike for an implicit module build,
we don't need nor want to require these flags to match between the module
and its users.
llvm-svn: 220780
Summary:
We should avoid a tail padding not only if the last field
has zero size but also if the last field is a struct with a flexible array.
If/when http://reviews.llvm.org/D5478 is committed,
this will also handle the case of structs with zero-sized arrays.
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5924
llvm-svn: 220708
This includes adding the new TypoExpr-based lazy typo correction to
LookupMemberExprInRecord as an alternative to the existing eager typo
correction.
llvm-svn: 220698
Add a fake linker in to a sysroot to use for testing the driver's tool
invocation. Should make the test behave similarly on all platforms. Addresses
review comments from Reid Kleckner from SVN r220546.
llvm-svn: 220625
We would crash because we used operator[] to access past the end of a
SmallString. This occured because our token had length zero.
Instead, form the pointer using .data() and arithmetic. This is safe
because this forms a one-past-the-end pointer and it is only used to
compare with another one-past-the-end pointer.
This fixes PR21379.
llvm-svn: 220614
The MS linker cannot do anything interesting with these, it doesn't make
sense to emit them.
This fixes PR21373.
Differential Revision: http://reviews.llvm.org/D5986
llvm-svn: 220595
Avoid an assertion when materializing a lifetime type aggregate temporary. When
performing CodeGen for ObjC++, we could generate a lifetime-only aggregate
temporary by using an initializer list (which is effectively an array). We
would reach through the temporary expression, fishing out the inner expression.
If this expression was a lifetime expression, we would attempt to emit this as a
scalar. This would eventually result in an assertion as the emission would
eventually assert that the expression being emitted has a scalar evaluation
kind.
Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the
aggregate expression rather than the EmitScalarInit.
Addresses PR21347.
llvm-svn: 220590
Template template parameters weren't added to the list of substitutions.
This would make the substitution map contain inaccurate mappings,
leading to Clang violating the Itanium ABI and breaking compatibility
with GCC.
This fixes PR21351.
Differential Revision: http://reviews.llvm.org/D5959
llvm-svn: 220588
This fixes a corner-case where __uuidof as a template argument would
result in us trying to emit a GLValue as an RValue. This would lead to
a crash down the road.
llvm-svn: 220585
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
Summary:
This allows us to easily identify them in the backend which in turn allows us
to handle them correctly for big-endian targets (where they must be shifted
into the upper bits of the register).
Depends on D5961
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5962
llvm-svn: 220566
Summary:
Ensure all integral/enumeration types are appropriately annotated with
signext/zeroext. In particular, i32 now has these attributes when using the
N32/N64 ABI. This paves the way for accurately representing the way the
N32/N64 ABI's promotes integer arguments to i64.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5961
llvm-svn: 220563
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
This is a very basic toolchain. It supports cross-compiling Windows (primarily
inspired by the WoA target). It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld). It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.
It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib). It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).
The entry point stub is responsible for running any GNU constructors.
llvm-svn: 220546
Clang would previously assert on the following code when targeting MinGW:
struct __declspec(dllimport) S {
virtual ~S();
};
S::~S() {}
Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.
Differential Revision: http://reviews.llvm.org/D5944
llvm-svn: 220532
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
nonnull attribute when comparison is always
true/false. Patch by Steven Wu with few fixes and minor
refactoring and adding tests by me. rdar://18712242
llvm-svn: 220496
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
llvm-svn: 220493
The previous IR representation used the non-lexical decl context, which
placed the definitions in the same scope as the declarations (ie: within
the class) - this was hidden by the fact that LLVM currently doesn't
respect the context of global variable definitions at all, and always
puts them at the top level (as direct children of the compile_unit).
Having the correct lexical scope improves source fidelity and simplify
backend global variable emission (with changes coming shortly).
Doing something similar for non-member global variables would help
simplify/cleanup things further (see FIXME in the commit) and provide
similar source fidelity benefits to the final debug info.
llvm-svn: 220488
This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.
llvm-svn: 220460
This is a sad thing to do, but all the alternatives look ugly.
Looks like there are legitimate cases when users may want to link
with sanitizer runtimes *and* -nodefaultlibs (and ensure they provide
replacements for system libraries). For example, this happens in libc++
test suite.
"-nodefaultlibs" is told to link only the libraries explicitly provided
by the user, and providing "-fsanitize=address" is a clear indication of
intention to link with ASan runtime.
We can't easily introduce analogue of "-print-libgcc-name": linking with
sanitizers runtimes is not trivial: some runtimes are split into several
archive libraries, which are required to be wrapped in
-whole-archive/-no-whole-archive.
If "-fsanitize=whatever" and "-nodefaultlibs" are provided, system library
dependencies of sanitizer runtimes (-lc/-ldl/-lpthread/-lrt) will *not* be
linked, and user would have to link them in manually. Note that this can
cause problems, as failing to provide "-lrt" might lead to crashes in runtime
during ASan initialization. But looks like we should bite this bullet.
See r218541 review thread for the discussion.
llvm-svn: 220455
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
When SanitizerBlacklist decides if the SourceLocation is blacklisted,
we need to first turn it into a SpellingLoc before fetching the filename
and scanning "src:" entries. Otherwise we will fail to fecth the
correct filename for function definitions coming from macro expansion.
llvm-svn: 220403
This eliminates some i8* GEPs and makes the IR that clang emits a bit
more canonical. More work is needed for vftables, but that isn't a clear
win so I plan to send it for review.
llvm-svn: 220398
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch tells the driver to only emit source location tracking
when -fprofile-sample-use is present in the command line.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5888
llvm-svn: 220383
If a templated class is not instantiated, then the AST for it could be missing
some things that would throw the field checker off. Wait until specialization
before emitting these warnings.
llvm-svn: 220363
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.
llvm-svn: 220343
-g1 on gcc (and also IBM's xlc) are documented to be very similar to
-gline-tables-only. Our -gline-tables-only might still be more verbose than -g1
on other compilers, but currently we treat -g1 as -g, and so we're producing
much more debug info at -g1 than everybody else. Treating -g1 as
-gline-tables-only brings us much closer to what everyone else is doing.
For more information, see the discussion on
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039649.html
llvm-svn: 220311
This fixes crash report generation when filenames have spaces. It also
removes an awkward workaround that quoted *some* arguments when
generating crash reports.
llvm-svn: 220307
This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D4752
llvm-svn: 220262
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
llvm-svn: 220175
This commit caused two tests in LNT to regress. I'm able to reproduce on
any platform and will send reproduction steps to the original commit
log. This should restore the LNT bots that have been failing.
llvm-svn: 220169
a NaN-test prior to the call to the library function.
This should automatically make fastmath (including just non-NaNs) able to avoid
the expensive libcalls and also open the door to more advanced folding in LLVM
based on the rules for complex math.
Two important notes to remember: first is that this isn't yet a proper
limited range mode, it's still just improving the unlimited range mode.
Also, it isn't really perfecet w.r.t. what an unlimited range mode
should be doing because it isn't quite handling the flags produced by
all the operations in the way desirable for that mode, but then neither
is compiler-rt's libcall. When the compiler-rt libcall is improved to
carefully manage flags, the code emitted here should be improved
correspondingly. And it is still a long-term desirable thing to add
a limited range mode to Clang that would be able to use direct math
without library calls here.
Special thanks to Steve Canon for the careful review on this patch and
teaching me about these issues. =D
Differential Revision: http://reviews.llvm.org/D5756
llvm-svn: 220167
This suppresses a common false positive when analyzing libc++.
Along the way, introduce some tests to show this checker actually
works with C++ static_cast<>.
llvm-svn: 220160
Before, ConstStructBuilder::AppendBytes would check packed constraints
prior to padding being added before the field's offset. However, adding
this padding might force our struct to be packed. Because we wouldn't
check *after* adding padding, ConstStructBuilder would be in an
inconsistent state leading to a crash.
This fixes PR21300.
llvm-svn: 220153
clang tests were breaking, at least when compiling clang only, from an
installed llvm. Make the lit.cfg script deal with the case when we don't
have a host_triple available.
llvm-svn: 220148
This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:
1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.
2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.
3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().
After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).
llvm-svn: 220097
template specialization type dependent, even if it has no dependent template
arguments. I've filed a corresponding bug against the C++ standard.
llvm-svn: 220088
of a member function of a class template that is defined outside the template.
This substitution can actually fail in some weird cases.
llvm-svn: 220085
Clang would previously not get into C++ mode when invoked as 'clang++3.6'
(though clang++-3.6 would work).
I found the previous loop logic in this function confusing; hopefully this
makes it a little clearer.
Differential Revision: http://reviews.llvm.org/D5833
llvm-svn: 220052
It broke some builders. I guess it'd be reproducible with --vg.
Failing Tests (3):
Clang :: CXX/except/except.spec/p1.cpp
Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp
Clang :: SemaTemplate/instantiate-exception-spec.cpp
llvm-svn: 220038
non-dependent types, in CXXScalarValueInitExprs and in the
nested-name-specifier or template arguments of a DeclRefExpr in particular.
llvm-svn: 220028
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
reverted in r218058 because they triggered a rejects-valid bug in MSVC.
Original commit message from r217995:
Instantiate exception specifications when instantiating function types (other
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
llvm-svn: 219977
A second instance of attributed types escaped the previous change, identified
thanks to Richard Smith! When deducing the void case, we would also assume that
the type would not be attributed. Furthermore, properly handle multiple
attributes being applied to a single TypeLoc.
Properly handle this case and future-proof a bit by ignoring parenthesis
further. The test cases do use the additional parenthesis to ensure that this
case remains properly handled.
Addresses post-commit review comments from Richard Smith to SVN r219851.
llvm-svn: 219974
Summary:
The general approach is to add extra paddings after every field
in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings
(CodeGen/CGClass.cpp).
Everything is done under the flag -fsanitize-address-field-padding.
The blacklist file (-fsanitize-blacklist) allows to avoid the transformation
for given classes or source files.
See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding
Reviewers: samsonov, rnk, rsmith
Reviewed By: rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D5687
llvm-svn: 219961
They cannot be written to, so marking them const makes sense and may improve
optimisation.
As a side-effect, SectionInfos has to be moved from Sema to ASTContext.
It also fixes this problem, that occurs when compiling ATL:
warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes
The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.
Differential Revision: http://reviews.llvm.org/D5812
llvm-svn: 219960
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
Fix for clang crash when instantiating a template with qualified lookup for members in non-class types.
Differential Revision: http://reviews.llvm.org/D5769
llvm-svn: 219897
Aaron Ballman