| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
|
| |
|
|
| |
llvm-svn: 237383
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237368
|
| |
|
|
|
|
| |
This fixes PR23414 as well.
llvm-svn: 237348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
llvm-svn: 237299
|
| |
|
|
|
|
|
|
|
| |
but not referenced.
Sadly, LLVM_ATTRIBUTE_UNUSED does nothing with Visual C++ which means
we'll have to workaround such cases again and again.
llvm-svn: 237267
|
| |
|
|
|
|
| |
lop based directives.
llvm-svn: 237102
|
| |
|
|
|
|
| |
'schedule' clause for combined directives requires additional processing. Special helper variable is generated, that is captured in the outlined parallel region for 'parallel for' region. This captured variable is used to store chunk expression from the 'schedule' clause in this 'parallel for' region.
llvm-svn: 237100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function template earlier.
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
This re-commits r236063, which was reverted in r236134, along with a fix for a
delayed template parsing bug that was exposed by this change.
llvm-svn: 237064
|
| |
|
|
|
|
|
| |
We now use an enum which maps the marketing name (almost always a year)
to the major version number.
llvm-svn: 236967
|
| |
|
|
|
|
|
| |
MSVC 2015 changed behavior from 2013; it imports move assignment
operators.
llvm-svn: 236966
|
| |
|
|
| |
llvm-svn: 236821
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A LambdaCapture does not have sufficient information
to correctly determine whether it is an init-capture or not.
Doing so requires knowledge held in the LambdaExpr itself.
It the case of a nested capture of an init-capture it is not
sufficient to check (as LambdaCapture::isInitCapture did)
whether the associated VarDecl was from an init-capture.
This patch moves isInitCapture to LambdaExpr and updates
Capture->isInitCapture() to Lambda->isInitCapture(Capture).
llvm-svn: 236760
|
| |
|
|
|
|
| |
imported but not visible definition.
llvm-svn: 236690
|
| |
|
|
|
|
|
|
| |
Fixed codegen for reduction operations min, max, && and ||. Codegen for them is quite similar and I was confused by this similarity.
Also added a call to kmpc_end_reduce() in atomic part of reduction codegen (call to kmpc_end_reduce_nowait() is not required).
Differential Revision: http://reviews.llvm.org/D9513
llvm-svn: 236689
|
| |
|
|
|
|
|
| |
declaration, ensure the loop variable is properly marked as invalid when
it is an "auto" variable.
llvm-svn: 236682
|
| |
|
|
| |
llvm-svn: 236574
|
| |
|
|
|
|
|
|
| |
magick/attribute.c
Allow to use variables with 'register' storage class as loop control variables in OpenMP loop based constructs.
llvm-svn: 236571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds low-level builtins to allow access to all of the z13 vector
instructions. Note that instructions whose semantics can be described
by standard C (including clang extensions) do not get any builtins.
For each instructions whose semantics *cannot* (fully) be described, we
define a builtin named __builtin_s390_<insn> that directly maps to this
instruction. These are intended to be compatible with GCC.
For instructions that also set the condition code, the builtin will take
an extra argument of type "int *" at the end. The integer pointed to by
this argument will be set to the post-instruction CC value.
For many instructions, the low-level builtin is mapped to the corresponding
LLVM IR intrinsic. However, a number of instructions can be represented
in standard LLVM IR without requiring use of a target intrinsic.
Some instructions require immediate integer operands within a certain
range. Those are verified at the Sema level.
Based on a patch by Richard Sandiford.
llvm-svn: 236532
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to prevent a TypoExpr from being corrected to a variable
when the TypoExpr is a subexpression of that variable's initializer.
Also exclude more keywords from the correction candidate pool when the
subsequent token is .* or ->* since keywords like "new" or "return"
aren't valid on the left side of those operators.
Fixes PR23140.
llvm-svn: 236519
|
| |
|
|
| |
llvm-svn: 236431
|
| |
|
|
|
|
|
|
|
|
|
| |
If a class is absent from instantiation and is incomplete, instantiate it as
an incomplete class thus avoiding compiler crash.
This change fixes PR18653.
Differential Revision: http://reviews.llvm.org/D8281
llvm-svn: 236426
|
| |
|
|
| |
llvm-svn: 236315
|
| |
|
|
| |
llvm-svn: 236301
|
| |
|
|
|
|
|
| |
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
|
| |
|
|
|
|
| |
lib/Basic/Targets.cpp
llvm-svn: 236274
|
| |
|
|
| |
llvm-svn: 236271
|
| |
|
|
|
|
|
|
|
|
| |
unavailable.
This probably won't come up much, but it seems tidier.
Related to rdar://problem/20713550
llvm-svn: 236242
|
| |
|
|
|
|
|
| |
For proper codegen we need to capture variable in the OpenMP region. In loop-based directives loop control variables are private by default and they must be captured in this region. There was a problem with capturing of globals, used as lcv, as they was not marked as private by default.
Differential Revision: http://reviews.llvm.org/D9336
llvm-svn: 236201
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
|
| |
|
|
| |
llvm-svn: 236167
|
| |
|
|
|
|
| |
emitted as a memcpy.
llvm-svn: 236142
|
| |
|
|
| |
llvm-svn: 236134
|
| |
|
|
|
|
|
| |
Basic __finally blocks don't cause linker errors anymore (although they
are miscompiled).
llvm-svn: 236128
|
| |
|
|
| |
llvm-svn: 236082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
llvm-svn: 236075
|
| |
|
|
|
|
|
|
|
|
|
|
| |
function template earlier.
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
llvm-svn: 236063
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just the clang-side of 32-bit SEH. LLVM still needs work, and it
will determinstically fail to compile until it's feature complete.
On x86, all outlined handlers have no parameters, but they do implicitly
take the EBP value passed in and use it to address locals of the parent
frame. We model this with llvm.frameaddress(1).
This works (mostly), but __finally block inlining can break it. For now,
we apply the 'noinline' attribute. If we really want to inline __finally
blocks on 32-bit x86, we should teach the inliner how to untangle
frameescape and framerecover.
Promote the error diagnostic from codegen to sema. It now rejects SEH on
non-Windows platforms. LLVM doesn't implement SEH on non-x86 Windows
platforms, but there's nothing preventing it.
llvm-svn: 236052
|
| |
|
|
| |
llvm-svn: 236043
|
| |
|
|
|
|
| |
device-side compilation.
llvm-svn: 236029
|
| |
|
|
|
|
|
|
| |
overloaded methods
http://reviews.llvm.org/D9261
llvm-svn: 236006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inclass initializer is instantiated in its own LocalInstantiationScope. It
causes problems when instantiating local classes - when instantiation scope
is searched for DeclContext of the field, the search fails. As a solution,
the instantiation scope of field initializer is combined with its outer
scope.
This patch fixes PR23194.
Differential Revision: http://reviews.llvm.org/D9258
llvm-svn: 236005
|
| |
|
|
|
|
| |
r235981, but is still NFC.
llvm-svn: 236002
|
| |
|
|
| |
llvm-svn: 235981
|
| |
|
|
|
|
| |
PR15842.
llvm-svn: 235931
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
right context.
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
device compilation.
During device-side CUDA compilation clang currently complains about
all TLS variables, regardless of whether they are __host__ or
__device__.
This patch suppresses "TLS unsupported" errors for host variables
during device compilation and for device variables during host
compilation.
Differential Revision: http://reviews.llvm.org/D9269
llvm-svn: 235907
|
| |
|
|
| |
llvm-svn: 235838
|
| |
|
|
|
|
|
|
|
| |
We could probably make this work if we cared enough. However, we are
far outside any language rules at this point.
This fixes PR21834.
llvm-svn: 235818
|
| |
|
|
|
|
|
|
| |
VerifyBitField must be called if we are to form a bitfield FieldDecl.
We will not verify the bitfield if the decl is known to be malformed in
other ways; pretend that we don't have a bitfield if this happens.
llvm-svn: 235816
|