PS4 target recognizes the #pragma comment() syntax as in -fms-extensions, but
only handles the case of #pragma comment(lib). This patch adds a warning if any
other arguments are encountered.
This patch also refactors the code in ParsePragma.cpp a little bit to make it
more obvious that some codes are being shared between -fms-extensions and PS4.
llvm-svn: 233015
Get rid of "libclang_rt.san" library that used to contain
sanitizer_common pieces required by UBSan if it's used in a standalone
mode. Instead, build two variants of UBSan runtime: "ubsan" and
"ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx").
Later "ubsan" and "ubsan_cxx" libraries will go away, as they will
embedded it into corresponding ASan runtimes.
llvm-svn: 233010
Simplify boolean expressions using `true` and `false` with `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8531
llvm-svn: 232999
On AArch64, the -fallow-half-args-and-returns option is the default.
With it, the half type is considered legal (rather than the i16 used
normally for __fp16), but no operation is, except conversions and
load/stores and such.
The previous behavior was tantamount to saying LangOpts.NativeHalfType
was implied by LangOpts.HalfArgsAndReturns, which isn't true.
Instead, teach the various parts of CodeGen that already know about
half (using the intrinsics or not) about this weird in-between case,
where the "half" type is legal, but operations on it aren't.
This is a smaller intermediate step to the end-goal of removing the
intrinsic, always using "half", and letting the backend legalize.
Builds on r232968.
rdar://20045970, rdar://17468714
Differential Revision: http://reviews.llvm.org/D8367
llvm-svn: 232971
Fix the CodeGen so that for types bigger than float, instead of
converting to fp16 via the sequence "InTy -> float -> fp16", we
perform conversions in just one step. This avoids the double
rounding which potentially changes results from a natural
IEEE-754 operation.
rdar://17594379, rdar://17468714
Differential Revision: http://reviews.llvm.org/D4602
Part of: http://reviews.llvm.org/D8367
llvm-svn: 232968
If there is at least one 'copyprivate' clause is associated with the single directive, the following code is generated:
```
i32 did_it = 0; \\ for 'copyprivate' clause
if(__kmpc_single(ident_t *, gtid)) {
SingleOpGen();
__kmpc_end_single(ident_t *, gtid);
did_it = 1; \\ for 'copyprivate' clause
}
<copyprivate_list>[0] = &var0;
...
<copyprivate_list>[n] = &varn;
call __kmpc_copyprivate(ident_t *, gtid, <copyprivate_list_size>,
<copyprivate_list>, <copy_func>, did_it);
...
void<copy_func>(void *LHSArg, void *RHSArg) {
Dst = (void * [n])(LHSArg);
Src = (void * [n])(RHSArg);
Dst[0] = Src[0];
... Dst[n] = Src[n];
}
```
All list items from all 'copyprivate' clauses are gathered into single <copyprivate list> (<copyprivate_list_size> is a size in bytes of this list) and <copy_func> is used to propagate values of private or threadprivate variables from the 'single' region to other implicit threads from outer 'parallel' region.
Differential Revision: http://reviews.llvm.org/D8410
llvm-svn: 232932
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
llvm-svn: 232928
The deduplication here is negligible, but it allows the compiler to
skip emission of many templated base class destructors. Shrinks
clang-query by 53k. No functionality change intended.
llvm-svn: 232924
This allows dumping to any given output stream but without requiring a SourceManager, similar to the interface provided by Decl.
It's useful when writing certain generic debug functions, external to the clang code base (for e.g.).
llvm-svn: 232912
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
llvm-svn: 232906
The diff looks intimidating, but this just moves the -Wdynamic-class-memaccess
code out a scope, protected by a
if (PointeeTy == QualType())
continue;
check so that it still only runs when it should.
llvm-svn: 232899
The linear variable is privatized (similar to 'private') and its
value on current iteration is calculated, similar to the loop
counter variables.
Differential revision: http://reviews.llvm.org/D8375
llvm-svn: 232890
the target-cpu, if different from the triple's cpu, and
target-features as they're written that are passed down from the
driver.
Together with LLVM r232885 this should allow the LTO'ing of binaries
that contain modules compiled with different code generation options
on a subset of architectures with full backend support (x86, powerpc,
aarch64).
llvm-svn: 232888
give an exception specification to a declaration that didn't have an exception
specification in any of our imported modules, emit an update record ourselves.
Without this, code importing the current module would not see an exception
specification that we could see and might have relied on.
llvm-svn: 232870
Summary:
We were claiming the -f*exceptions arguments when looking for the
RTTIMode. This makes us not warn about unused arguments if compiling a C
file with -fcxx-exceptions.
This patch fixes it by not claiming the exception-related arguments at
that point.
Reviewers: rsmith, samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8507
llvm-svn: 232860
Similarly, don't assume +0 if the property's setter is manually implemented.
In both cases, if the property's ownership is explicitly written, then we /do/
assume the ivar has the same ownership.
rdar://problem/20218183
llvm-svn: 232849
We are not able to make a reliable solution for using UBSan together
with other sanitizers with runtime support (and sanitizer_common).
Instead, we want to follow the path used for LSan: have a "standalone"
UBSan tool, and plug-in UBSan that would be explicitly embedded into
specific sanitizers (in short term, it will be only ASan).
llvm-svn: 232829
MS compiler emits no errors in case of explicit specializations outside declaration enclosing namespaces, even when language extensions are disabled.
The patch is to suppress errors and emit extension warnings if explicit specializations are not declared in the corresponding namespaces.
This fixes PR13738.
Patch by Alexey Frolov.
Differential Revision: http://reviews.llvm.org/D8283
llvm-svn: 232800
When we instrument a program for profiling, we copy the linkage of an
instrumented function so that our datastructures merge in the same way
as the function. This avoids redundant copies for things like
linkonce, but ends up emitting names we never need to reference for
normal and internal symbols. Promoting internal and external linkage
to private for these variables reduces the size overhead of profiling
drastically.
llvm-svn: 232799
When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.
This unnecessary work was papering over some other bugs:
- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.
- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).
llvm-svn: 232793
A WIP patch to turn on stricter `DIDescriptor` accessor checks fires
here; it's obvious from the code that `T` can be null, so add an
explicit check. Caught by dozens of current testcases.
llvm-svn: 232791
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
llvm-svn: 232788
We assumed that the most recent declaration of an inline function would
also be inline. However, a more recent declaration can come from a
friend declaration in a class template that is instantiated at the
definition of the function.
llvm-svn: 232786
Somehow, we never managed to implement this fully. We could constant
fold it like crazy, including constant folding complex arguments, etc.
But if you actually needed to generate code for it, error.
I've implemented it using the somewhat obvious lowering. Happy for
suggestions on a more clever way to lower this.
Now, what you might ask does this have to do with modules? Fun story. So
it turns out that libstdc++ actually uses __builtin_isinf_sign to
implement std::isinf when in C++98 mode, but only inside of a template.
So if we're lucky, and we never instantiate that, everything is good.
But once we try to instantiate that template function, we need this
builtin. All of my customers at least are using C++11 and so they never
hit this code path.
But what does that have to do with modules? Fun story. So it turns out
that with modules we actually observe a bunch of bugs in libstdc++ where
their <cmath> header clobbers things exposed by <math.h>. To fix these,
we have to provide global function definitions to replace the macros
that C99 would have used. And it turns out that ::isinf needs to be
implemented using the exact semantics used by the C++98 variant of
std::isinf. And so I started to fix this bug in libstdc++ and ceased to
be able to compile libstdc++ with Clang.
The yaks are legion.
llvm-svn: 232778
consider C++ that looks like:
inline int &f(bool b) {
if (b) {
static int i;
return i;
}
static int i;
return i;
}
Both 'i' variables must have distinct (and stable) names for linkage
purposes. The MSVC 2013 ABI would number the variables using a count of
the number of scopes that have been created. However, the final 'i'
returns to a scope that has already been created leading to a mangling
collision.
MSVC 2015 fixes this by giving the second 'i' the name it would have if
it were declared before the 'if'. However, this results in ABI breakage
because the mangled name, in cases where there was no ambiguity, would
now be different.
We implement the new behavior and only enable it if we are targeting the
MSVC 2015 ABI, otherwise the old behavior will be used.
This fixes PR18131.
llvm-svn: 232766
This warns when using decls that are not available on all deployment targets.
For example, a call to
- (void)ppartialMethod __attribute__((availability(macosx,introduced=10.8)));
will warn if -mmacosx-version-min is set to less than 10.8.
To silence the warning, one has to explicitly redeclare the method like so:
@interface Whatever(MountainLionAPI)
- (void)ppartialMethod;
@end
This way, one cannot accidentally call a function that isn't available
everywhere. Having to add the redeclaration will hopefully remind the user
to add an explicit respondsToSelector: call as well.
Some projects build against old SDKs to get this effect, but building against
old SDKs suppresses some bug fixes -- see http://crbug.com/463171 for examples.
The hope is that SDK headers are annotated well enough with availability
attributes that new SDK + this warning offers the same amount of protection
as using an old SDK.
llvm-svn: 232750
This reverts commit r230580.
extern_weak functions don't appear to work on Darwin (PR22951), so we'll
need to come up with a new approach.
llvm-svn: 232731
We know all subclasses in tblgen so just generate a giant switch for
the few virtual methods or turn them into a member variable using spare
bits. The giant jump tables aren't pretty but still much smaller than
a vtable for every attribute, shrinking Release+Asserts clang by ~400k.
Also halves the size of the Attr base class. No functional change
intended.
llvm-svn: 232726
There will be an explicit template instantiation in another translation
unit which will provide the definition of the VF/VB-Tables.
This fixes PR22932.
llvm-svn: 232680
Construction of LocalInstantiationScope automatically updates the current scope
inside Sema. However, when cloning a scope, the current scope does not change.
Change the cloning function to preserve the current scope.
Review: http://reviews.llvm.org/D8407
BUG: https://llvm.org/bugs/show_bug.cgi?id=22931
llvm-svn: 232675
spacing also fixed by r230473.
The fix in r230473 was done to enable fixing the spacing for
std::function<void( int, int )>.
I did not realized that it also fixed this
issue. Since it is fairly different from
Deleted &operator=(const Deleted &)& = default;
fixed in r230473, it seems sensible to add the regression test for it.
Also cleaned up the test by removing duplicated code and comment, and kept
repeated test set consistent.
Result of running the new tests with r230473 backed out:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
Actual: "std::function<void(int, int)> callback;"
Expected: "std::function<void( int, int )> callback;"
Actual: "std::function<void( int, int )> callback;"
Expected: "std::function<void(int, int)> callback;"
Actual: "std::function<void( int, int ) > callback;"
Expected: "std::function<void(int, int)> callback;"
[ FAILED ] FormatTest.ConfigurableSpacesInParentheses (402 ms)
Result of new tests with r230473:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
[ OK ] FormatTest.ConfigurableSpacesInParentheses (209 ms)
Review: http://reviews.llvm.org/D7922
Patch by Jean-Philippe Dufraigne. Thanks!
llvm-svn: 232632
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being not accepted for OpenCL
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 232631
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
These calls are usually guarded by checks for isAnnotation() but it
looks like we missed a spot. This would cause the included test to
crash clang.
llvm-svn: 232616
We disabled support for _Atomic because the STL had name conflicts,
they've been resolved in 2015. Similarly, reenable char16_t and
char32_t.
llvm-svn: 232611
Codegen for threadprivate variables (and in some other cases) may cause crash of the compiler if some diagnostic is produced later. This happens because some of the autogenerated globals are not removed from InternalVars StringMap when llvm::Module is reset.
Differential Revision: http://reviews.llvm.org/D8360
llvm-svn: 232610
We used to support the 2013 mangling and changed it to the more
reasonable 2015 mangling. Let's make the mangling conditional on what
version of MSVC is targeted.
This fixes PR21888.
llvm-svn: 232609
consumers of that module.
Previously, such a file would only be available if the module happened to
actually import something from that module.
llvm-svn: 232583
contained a typo correction (the auto decl was being marked as dependent
unnecessarily, which triggered an assertion in cases where the size of
the type is needed).
llvm-svn: 232568
Summary: As discussed in D8097, we should provide corresponding linking flags when 'fveclib' is specified.
Reviewers: hfinkel
Differential Revision: http://reviews.llvm.org/D8362
llvm-svn: 232556
The HandlerMap describes, to the runtime, what sort of catches surround
the try. In principle, this structure has to be emitted by the backend
because only it knows the layout of the stack (the runtime needs to know
where on the stack the destination of a copy lives, etc.) but there is
some C++ specific information that the backend can't reason about.
Stick this information in special LLVM globals with the relevant
"const", "volatile", "reference" info mangled into the name.
llvm-svn: 232538
Previously, we would error out on this code because the default argument
wasn't parsed until the end of Outer:
struct __declspec(dllexport) Outer {
struct __declspec(dllexport) Inner {
Inner(void *p = 0);
};
};
Now we do the checking on the closing brace of Outer instead of Inner.
llvm-svn: 232519
ARMv6K is another layer between ARMV6 and ARMV6T2. This is the Clang
side of the changes.
ARMV6 family LLVM implementation.
+-------------------------------------+
| ARMV6 |
+----------------+--------------------+
| ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors
+----------------+--------------------+ have support for hint instructions
| ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can
+-------------------------------------+ be either real or default to NOP.
| ARMV7 (arm,thumb,thumb2) | The two processors also use
+-------------------------------------+ different encoding for them.
Patch by Vinicius Tinti.
llvm-svn: 232469
namespace to not merge properly.
We have an invariant here: after a declaration reads its canonical declaration,
it can assume the canonical declaration is fully merged. This invariant can be
violated if deserializing some declaration triggers the deserialization of a
later declaration, because that later declaration can in turn deserialize a
redeclaration of that first declaration before it is fully merged.
The anonymous namespace for a namespace gets stored with the first declaration
of that namespace, which may be before its parent namespace, so defer loading
it until after we've finished merging the surrounding namespace.
llvm-svn: 232455
Add a frontend test for PR22929, which was fixed by LLVM r232449.
Besides the crash test, check that the `!dbg` attachment is sane since
its presence was the trigger.
llvm-svn: 232450
This exposes the optional exit block placement logic from r232438 as a
clang -cc1 option. There is a test on the llvm side, but there isn't
really a way to inspect the gcov options from clang to test it here as
well.
llvm-svn: 232439
building its redecl chains, make sure we pull in the redeclarations of those
canonical declarations.
It's pretty difficult to reach a situation where we can find more canonical
declarations of an entity while building its redecl chains; I think the
provided testcase (4 modules and 7 declarations) cannot be reduced further.
llvm-svn: 232411
location data is available. If pragma handling wants to look up the
position, it finds the LLVM buffer and wants to compare it with the
special built-in buffer, failing badly. Extend to the special handling
of the built-in buffer to also check for the inline asm buffer. Expect
only a single asm buffer. Sort it between the built-in buffers and the
normal file buffers.
Fixes the assert part of PR 22576.
llvm-svn: 232389
Summary: This patch consists of the suggestions of clang-tidy/misc-static-assert check.
Reviewers: alexfh
Subscribers: dblaikie, xazax.hun, cfe-commits
Differential Revision: http://reviews.llvm.org/D8344
Patch by Szabolcs Sipos!
llvm-svn: 232367
This basically creates a wrapper around an 'int' that poses as an iterator.
While that looks a bit counter-intuitive it works just fine because iterator
operations and basic integer arithmetic works in exactly the same way.
Remove the manual integer wrapping code and reduce the reliance on iterator
internals in the implementation. No functionality change intended.
llvm-svn: 232322
The current enum detection is overly aggressive. As NestingLevel only
applies per line (?) it classifies many if not most object literals as
enum declarations and adds superfluous line breaks into them. This
change narrows the heuristic by requiring an assignment just before the
open brace and requiring the line to start with an identifier.
Patch by Martin Probst. Thank you.
llvm-svn: 232320
Qualifiers are located next to the TypeDescriptor in order to properly
ensure that a pointer type can only be caught by a more qualified catch
handler. This means that a catch handler of type 'const int *' requires
an RTTI object for 'int *'. We got this correct for 'throw' but not for
'catch'.
N.B. We don't currently have the means to store the qualifiers because
LLVM's EH strategy is tailored to the Itanium scheme. The Itanium ABI
stores qualifiers inside the type descriptor in such a way that the
manner of qualification is stored in addition to the pointee type's
descriptor. Perhaps the best way of modeling this for the MS ABI is
using an aggregate type to bundle the qualifiers with the descriptor?
This is tricky because we want to make it clear to the optimization
passes which catch handlers invalidate other handlers.
My current thoughts on a design for this is along the lines of:
{ { TypeDescriptor* TD, i32 QualifierFlags }, i32 MiscFlags }
The idea is that the inner most aggregate is all that is needed to
communicate that one catch handler might supercede another. The
'MiscFlags' field would be used to hold the bitpattern for the notion
that the 'catch' handler does not need to invoke a copy-constructor
because we are catching by reference.
llvm-svn: 232318
When if statement condition ended in a macro:
if (ptr == NULL);
the check used to consider the definition location of NULL, instead of the
current line.
Patch by Manasij Mukherjee.
llvm-svn: 232295
It is possible to construct an initializer for a bitfield which is not
constant. Instead of emitting code to initialize the field before the
execution of main, clang would crash.
llvm-svn: 232285
They're expensive to compare and we won't sort many of them so std::sort
doesn't give any benefits and causes code bloat. Func fact: clang -O3 didn't
even bother to inline libc++'s std::sort here.
While there validate the predicate a bit harder, the sort is unstable and we
don't want to introduce any non-determinism. I had to spell out the function
pointer type because GCC 4.7 still fails to convert the lambda to a function
pointer :(
No intended functionality change.
llvm-svn: 232263
Virtual member pointers are implemented using a thunk. We assumed that
the calling convention for this thunk was always __thiscall for 32-bit
targets and __cdecl for 64-bit targets. However, this is not the case.
Mangle in whichever calling convention is appropriate for this member
function thunk.
llvm-svn: 232254
with a subset of the existing target CPU features or mismatched CPU
names.
While we can't check that the CPU name used to build the module will end
up being able to codegen correctly for the translation unit, we actually
check that the imported features are a subset of the existing features.
While here, rewrite the code to use std::set_difference and have it
diagnose all of the differences found.
Test case added which walks the set relationships and ensures we
diagnose all the right cases and accept the others.
No functional change for implicit modules here, just better diagnostics.
llvm-svn: 232248
This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.
Differential Revision: http://reviews.llvm.org/D8312
llvm-svn: 232241
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
In preparation for recommit of revision 232190, change tests so that they
are resilient to operands being commuted by the reassociate pass.
llvm-svn: 232206
std::make_exception_ptr calls std::__GetExceptionInfo in order to figure
out how to properly copy the exception object.
Differential Revision: http://reviews.llvm.org/D8280
llvm-svn: 232188
This guarantees the order and doesn't increase malloc counts a lot as there are
typically very few elements int the map. Provide a little iterator adapter to
keep the same interface as we had with the flat sorted list.
No functional change intended.
llvm-svn: 232173
headers even if they arrived when merging non-system modules.
The idea of this code is that we don't want to warn the user about
macros defined multiple times by their system headers with slightly
different definitions. We should have this behavior if either the
macro comes from a system module, or the definition within the module
comes from a system header. Previously, we would warn on ambiguous
macros being merged when they came from a users modules even though they
only showed up via system headers.
By surviving this we can handle common system header macro differences
like differing 'const' qualification of pointers due to some headers
predating 'const' being valid in C code, even when those systems headers
are pre-built into a system module.
Differential Revision: http://reviews.llvm.org/D8310
llvm-svn: 232149
This is complicated by the fact that we can't simply use side-effecting
calls in an argument list without losing all guarantees about the order
they're emitted. To keep things deterministic we use tuples and brace
initialization, which thankfully guarantees evaluation order.
No functionality change intended.
llvm-svn: 232121
This is nearly identical to the v*f128_si256 parts of r231792 and r232052.
AVX2 introduced proper integer variants of the hacked integer insert/extract
C intrinsics that were created for this same functionality with AVX1.
This should complete the front end fixes for insert/extract128 intrinsics.
Corresponding LLVM patch to follow.
llvm-svn: 232109
A nullptr exception object can be caught by any pointer type catch
handler. However, it is not possible to express this in the exception
info for the MS ABI. As a middle ground, allow such exception objects
to be caught with pointer-to-void catch handlers.
llvm-svn: 232069
Update the doxygen configuration file and the Makefile build rules
to provide better output (simply use the default stylesheet and template
from the Doxygen distribution.)
This CL has upgrade doxygen.cfg.in to Doxygen 1.8.6.
llvm-svn: 232066
In a static build the dependency is picked up implictly, but not in a shared
library build. This is needed for the new ObjC matchers that reference Selector.
llvm-svn: 232055
This is very much like D8088 (checked in at r231792).
Now that we've replaced the vinsertf128 intrinsics,
do the same for their extract twins.
Differential Revision: http://reviews.llvm.org/D8275
llvm-svn: 232052
Add some matchers for Objective-C selectors and messages to
ASTMatchers.h. Minor mods to ASTMatchersTest.h to allow test files with
".m" extension in addition to ".cpp". New tests added to
ASTMatchersTest.c.
Patch by Dean Sutherland.
llvm-svn: 232051
Before:
A a = new A(){public String toString(){return "NotReallyA";
}
}
;
After:
A a = return new A() {
public String toString() {
return "NotReallyA";
}
};
This fixes llvm.org/PR22878.
llvm-svn: 232042
This is a bit more involved than I anticipated, so here's a breakdown
of the changes:
1. Call ActOnFinishFunctionBody _after_ we parsed =default and
=delete specifiers. Saying that we finished the body before parsing
=default is just wrong. Changing this allows us to use isDefaulted
and isDeleted on a decl in ActOnFinishFunctionBody.
2. Check for -Wmissing-prototypes after we parsed the function body.
3. Disable -Wmissing-prototypes when the Decl isDeleted.
llvm-svn: 232040
Sema overrides ASTContext's policy on the first emitted diagnostic
(doesn't matter if it's ignored or not). This means changing the order
of diagnostic emission in Sema suddenly changes the text of diagnostic
emitted from the parser.
In the test case -Wmissing-prototypes (ignored) was the culprit, use
'int main' to suppress that warning so we see when this regresses.
Also move it into Sema/ as it's not testing any C++.
llvm-svn: 232039
For crashes with a VFS (ie, with modules), the -isysroot flag is often
necessary to reproduce the crash. This is especially true if some
modules need to be rebuilt, since without the sysroot they'll try to
read headers that are outside of the VFS.
I find it likely that we should keep some of the other -i flags in
this case as well, but I haven't seen that come up in practice yet so
it seems better to be conservative.
llvm-svn: 231997
When a crash report script doesn't work for a reproduction on your
machine for one reason or another, it can be really tricky to figure
out why not. The compiler version that crashed and the original
command line before stripping flags are very helpful when this comes
up.
llvm-svn: 231989
Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.
llvm-svn: 231960
This adds support for copy-constructor closures. These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.
Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.
Differential Revision: http://reviews.llvm.org/D8225
llvm-svn: 231952
definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).
One-line fix by me; reduced testcase by Daniel Jasper!
llvm-svn: 231950
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being accepted only for c11 compilations
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 231932
CloudABI also supports the arc4random() function. We can enable compiler
warnings for rand(), random() and *rand48() on this system as well.
llvm-svn: 231914
CloudABI is a pure cross compilation target. This means that we should
not add /usr/include and /usr/local/include. Instead, headers are stored
in $sysroot/$triple/include.
The method of going back to the sysroot (by using "../../..") is also
used in this function for some of the other environments (e.g., MinGW).
llvm-svn: 231913
CloudABI can be identified by the __CloudABI__ preprocessor definition. The
system uses ELF executables.
CloudABI uses Unicode 7.0.0 for the encoding of wchar_t. As Unicode 7.0.0 is
synchronized with ISO/IEC 10646:2012 (released on 2012-06-01),
__STDC_ISO_10646__ is defined as 201206L.
llvm-svn: 231912
Using declarations which are aliases to struct types have their name
used as the struct type's name for linkage purposes. Otherwise, make
sure to give an anonymous struct defined inside a using declaration a
mangling number to disambiguate it from other anonymous structs in the
same context.
This fixes PR22809.
llvm-svn: 231909
This patch allows using of ExprWithCleanups expressions and other complex expressions in 'omp atomic' construct
Differential Revision: http://reviews.llvm.org/D8200
llvm-svn: 231905
Because the catchable type has a reference to its name, mangle the
location to ensure that two catchable types with different locations are
distinct.
llvm-svn: 231819
We do not implicitly create an OpenCLImageAccessAttr, so this change only affects out of tree users. There is no way to test this behavior specifically that I can see, since this only affects implicit creation of attributes.
Fixes PR22403.
llvm-svn: 231803
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.
This is the sibling patch for the LLVM half of this change:
http://reviews.llvm.org/D8086
Differential Revision: http://reviews.llvm.org/D8088
llvm-svn: 231792
Using clang as a cross-compiler with the 'target' option could be confusing
for those inexperienced in the realm of cross compiling.
This patch would allow the use of all these four variants of the target option:
-target <triple>
--target <triple>
-target=<triple>
--target=<triple>
Patch by Gabor Ballabas.
llvm-svn: 231787
The task region is emmitted in several steps:
Emit a call to kmp_task_t *__kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid, kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds, kmp_routine_entry_t *task_entry).
Here task_entry is a pointer to the function:
kmp_int32 .omp_task_entry.(kmp_int32 gtid, kmp_task_t *tt) {
TaskFunction(gtid, tt->part_id, tt->shareds);
return 0;
}
Copy a list of shared variables to field shareds of the resulting structure kmp_task_t returned by the previous call (if any).
Copy a pointer to destructions function to field destructions of the resulting structure kmp_task_t.
Emit a call to kmp_int32 __kmpc_omp_task(ident_t *, kmp_int32 gtid, kmp_task_t *new_task), where new_task is a resulting structure from previous items.
Differential Revision: http://reviews.llvm.org/D7560
llvm-svn: 231762
Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions
Differential Revision: http://reviews.llvm.org/D7935
llvm-svn: 231757
This reverts commit r231752.
It was failing to link with cmake:
lib64/libclangCodeGen.a(CGOpenMPRuntime.cpp.o):/home/espindola/llvm/llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:function clang::CodeGen::InlinedOpenMPRegionRAII::~InlinedOpenMPRegionRAII(): error: undefined reference to 'clang::CodeGen::EHScopeStack::popTerminate()'
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 231754
Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions
Differential Revision: http://reviews.llvm.org/D7935
llvm-svn: 231752
specification, update all prior declarations if the new one has an explicit
exception specification and the prior ones don't.
Patch by Vassil Vassilev! Some minor tweaking and test case by me.
llvm-svn: 231738
move the operator delete updating into a separate update record so we can cope
with updating another module's destructor's operator delete.
llvm-svn: 231735
check that private headers are in a list matching the role. (We can't perform
the opposite checks for non-private headers because we infer those.)
llvm-svn: 231728
This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.
Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.
llvm-svn: 231711
When passing a type with large alignment byval, we were specifying the type's
alignment rather than the alignment that the backend is actually capable of
producing (ABIAlign).
This would be OK (if odd) assuming the backend dealt with it prooperly,
unfortunately it doesn't and trying to pass types with "byval align 16" can
cause it to set fp incorrectly and trash the stack during the prologue. I'll be
fixing that in a separate patch, but Clang should still be emitting IR that's
as close to its intent as possible.
rdar://20059039
llvm-svn: 231706
override where at least a declaration of a designated initializer is in a super
class and not necessarily in the current class. rdar://19653785.
llvm-svn: 231700
This only warns on direct gotos and indirect gotos with a unique label
(`goto *&&label;`). Jumping out ith a true indirect goto is already an error.
This isn't O(1), but goto statements are less common than continue, break, and
return. Also, the GetDeepestCommonScope() call in the same function does the
same amount of work, so this isn't worse than what's there in a complexity
sense, and it should be pretty fast in practice.
This is the last piece that was missing in r231623.
llvm-svn: 231628
ParseCompoundStatement() currently never returns StmtError, but if it did,
Sema would keep the __finally scope on its stack indefinitely. Explicitly
add an error callback that clears it.
llvm-svn: 231625
Since continue, break, return are much more common than __finally, this tries
to keep the work for continue, break, return O(1). Sema keeps a stack of active
__finally scopes (to do this, ActOnSEHFinally() is split into
ActOnStartSEHFinally() and ActOnFinishSEHFinally()), and the various jump
statements then check if the current __finally scope (if present) is deeper
than then destination scope of the jump.
The same warning for goto statements is still missing.
This is the moral equivalent of MSVC's C4532.
llvm-svn: 231623
I disabled putting the new global into the same COMDAT as the function for now.
There's a fundamental problem when we inline references to the global but still
have the global in a COMDAT linked to the inlined function. Since this is only
an optimization there may be other versions of the COMDAT around that are
missing the new global and hell breaks loose at link time.
I hope the chromium build doesn't break this time :)
llvm-svn: 231564
simplicity in build systems, silence '-stdlib=libc++' when linking. Even
if we're not linking C++ code per-se, we may be passing this flag so
that when we are linking C++ code we pick up the desired standard
library. While most build systems already provide separate C and C++
compile flags, many conflate link flags. Sadly, CMake is among them
causing this warning in a libc++ selfhost.
llvm-svn: 231559
Fariborz Jahanian