Initial commit missed sincos(float), llabs() and few atomics that we
used to pull in from device_functions.hpp, which we no longer include.
Differential Revision: https://reviews.llvm.org/D43602
llvm-svn: 325814
* Add HelpText for -fopenmp so that it appears in clang --help.
* Hide -fno-openmp-simd, only list the positive option.
* Hide -fopenmp-relocatable-target and -fopenmp-use-tls from
clang --help and from ClangCommandLineReference.
* Improve MetaVarName for -Xopenmp-target=<...>.
Differential Revision: https://reviews.llvm.org/D42841
llvm-svn: 325806
We can't see how many arguments are in the meta var name, so just
assume that it is the right number.
Differential Revision: https://reviews.llvm.org/D42840
llvm-svn: 325805
Summary:
OpenCL 2.0 specification defines '-cl-uniform-work-group-size' option,
which requires that the global work-size be a multiple of the work-group
size specified to clEnqueueNDRangeKernel and allows optimizations that
are made possible by this restriction.
The patch introduces the support of this option.
To keep information about whether an OpenCL kernel has uniform work
group size or not, clang generates 'uniform-work-group-size' function
attribute for every kernel:
- "uniform-work-group-size"="true" for OpenCL 1.2 and lower,
- "uniform-work-group-size"="true" for OpenCL 2.0 and higher if
'-cl-uniform-work-group-size' option was specified,
- "uniform-work-group-size"="false" for OpenCL 2.0 and higher if no
'-cl-uniform-work-group-size' options was specified.
If the function is not an OpenCL kernel, 'uniform-work-group-size'
attribute isn't generated.
Patch by: krisb
Reviewers: yaxunl, Anastasia, b-sumner
Reviewed By: yaxunl, Anastasia
Subscribers: nhaehnle, yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D43570
llvm-svn: 325771
Summary:
- Using -lpthread instead, with -pthread the linkage does not work.
-Warning about the -fxray-instrument usage outside of the working cases.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, dberris, emaste
Reviewed By: krytarowski, emaste
Subscribers: srhines, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D43378
llvm-svn: 325746
Build the index off of DeclarationName instead of Decl pointers. When finding
an UnresolvedLookupExprClass, hash it as if it were a DeclRefExpr. This will
allow methods to be hashed.
llvm-svn: 325741
When using blocks with C++ on Windows x86, it is possible to have the
block literal be pushed into the inalloca'ed parameters. Teach IRGen to
handle the case properly by extracting the block literal from the
inalloca parameter. This fixes the use of blocks with C++ on Windows
x86.
llvm-svn: 325724
Summary:
D43522 caused an assertion failure when getStyle() was called with
an empty filename:
P8065
This adds a test to reproduce the failure and fixes the issue by
ensuring we never pass an empty filename to
Environment::CreateVirtualEnvironment().
Test Plan: New test added. Ran test with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Before diff, test failed with P8065. Now, test passes.
Reviewers: vsapsai, jolesiak, krasimir
Reviewed By: vsapsai
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43590
llvm-svn: 325722
The checker marks the locations where the analyzer creates sinks. However, it
can happen that the sink was created because of a loop which does not contain
condition statement, only breaks in the body. The exhausted block is the block
which should contain the condition but empty, in this case.
This change only emits this marking in order to avoid the undefined behavior.
Differential Revision: https://reviews.llvm.org/D42266
llvm-svn: 325693
Summary:
For clients which don't have a filesystem, calling getStyle() doesn't
make much sense (there's no .clang-format files to search for).
In this diff, I hoist out the language-guessing logic from getStyle()
and move it into a new API guessLanguage().
I also added support for guessing the language of files which have no
extension (they could be C++ or ObjC).
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: klimek, cfe-commits, sammccall
Differential Revision: https://reviews.llvm.org/D43522
llvm-svn: 325691
Summary:
According to [dcl.init.list]p7:
A narrowing conversion is an implicit conversion
- ...
- from an integer type or unscoped enumeration type to a
floating-point type, except where the source is a constant
expression and the actual value after conversion will fit into
the target type and will produce the original value when
converted back to the original type, or
- ...
Currently clang does not handle the 'unscoped enumeration' case. This
patch fixes the corresponding check.
Reviewers: faisalv, rsmith, rogfer01
Reviewed By: rogfer01
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D42545
llvm-svn: 325668
libClang is used by other Clang based tools such as cquery while
clang-include-fixer is generally a useful tool.
Differential Revision: https://reviews.llvm.org/D43404
llvm-svn: 325665
expressions, if their lifetime began during the evaluation of the expression.
This is technically not allowed in C++11, though we could consider permitting
it there too, as an extension.
llvm-svn: 325663
If the value returned by `malloc`, `calloc` or `realloc` is not checked
for null pointer, this change replaces them for `safe_malloc`,
`safe_calloc` or `safe_realloc`, which are defined in the namespace `llvm`.
These function report fatal error on out of memory.
In the plain C files, assertion statements are added to ensure that memory
is successfully allocated.
The aim of this change is to get better diagnostics of OOM on Windows.
Differential Revision: https://reviews.llvm.org/D43017
llvm-svn: 325661
Cannon Lake does not support CLWB, therefore it
does not include all features listed under SKX.
Patch by Gabor Buella
Differential Revision: https://reviews.llvm.org/D43459
llvm-svn: 325655
This patch provides mitigation for CVE-2017-5715, Spectre variant two,
which affects the P5600 and P6600. It provides the option
-mindirect-jump=hazard, which instructs the LLVM backend to replace
indirect branches with their hazard barrier variants.
This option is accepted when targeting MIPS revision two or later.
The migitation strategy suggested by MIPS for these processors is to
use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
barrier variants of the 'jalr' and 'jr' instructions respectively.
These instructions impede the execution of instruction stream until
architecturally defined hazards (changes to the instruction stream,
privileged registers which may affect execution) are cleared. These
instructions in MIPS' designs are not speculated past.
These instructions are used with the option -mindirect-jump=hazard
when branching indirectly and for indirect function calls.
These instructions are defined by the MIPS32R2 ISA, so this mitigation
method is not compatible with processors which implement an earlier
revision of the MIPS ISA.
Implementation note: I've opted to provide this as an
-mindirect-jump={hazard,...} style option in case alternative
mitigation methods are required for other implementations of the MIPS
ISA in future, e.g. retpoline style solutions.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D43487
llvm-svn: 325651
Ideally, we'd only use the ubsan blacklist for ubsan sanitizers, and only use
the other-sanitizer blacklist for its sanitizers, but this at least enables the
intended suppressions.
llvm-svn: 325640
This function did a lot of 'Diag, return true' stuff. This resulted in needing
to introduce scopes in quite a few places. This patch replaces useages of a
single "S.Diag" followed by return true with simply "return S.Diag".
llvm-svn: 325633
Multiversioning SEMA failed to set the declaration as invalid on unsupported
targets. This patch does that.
Additionally, I noticed that there is no test to validate this error message.
This patch adds one, and uses 'mips' as the test architecture.
llvm-svn: 325610
The proper approach is to rebuild libutil and libkvm with a desired sanitizer.
An alternative approach to reimplement these functions (and other ones like
curses(3), editline(3) etc) does not scale and enforces linkage every single
binary with these libraries.
llvm-svn: 325593
This broke Clang bootstrap on Windows, PR36453.
> This handles them exactly the same way that we handle const integral
> static data members with inline definitions, which is what MSVC does.
>
> As a follow-up, now that we have a way to mark variables inline in the
> AST, we should consider marking them implicitly inline there instead of
> only treating them as inline in CodeGen. Unfortunately, this breaks a
> lot of dllimport test cases, so that is future work for now.
>
> Fixes PR36125.
llvm-svn: 325576
This patch fixes creating TBAA access descriptors for
may_alias-marked access types. Currently, for such types we
generate ordinary descriptors with char as its access type. The
patch changes this to produce proper may-alias descriptors.
Differential Revision: https://reviews.llvm.org/D42366
llvm-svn: 325575
Reimplement the "noexcept function actually throws" warning to properly handle
nested try-blocks. In passing, change 'throw;' handling to treat any enclosing
try block as being sufficient to suppress the warning rather than requiring a
'catch (...)'; the warning is intended to be conservatively-correct.
llvm-svn: 325545
Summary:
This fixes the detection of scope openers in text proto extensions; previously
they were not detected correctly leading to instances like:
```
msg {
[aa.bb
] {
key: value
}
}
```
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43469
llvm-svn: 325513
Summary: This patch fixes a case where a proto message attribute is wrongly identified as an text proto extension.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43465
llvm-svn: 325509
CodeCompletionContext had declarations of field and enum inside, both named 'Kind'.
It caused gcc 4.8 to give an incorrent warning when refering to enum as
`enum CodeCompletionContext::Kind`.
Avoid that warning by renaming the private field to CCKind.
llvm-svn: 325496
To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,
-mfloat-abi=soft -fpu=neon
If any floating point features which require FPU hardware are enabled
they must be disable.
There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).
Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.
Differential Revision: https://reviews.llvm.org/D42569
llvm-svn: 325492
Summary: Will be used in clangd. See D43377.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D43379
llvm-svn: 325490
Summary:
`of` is only a keyword when after an identifier, but not when after
an actual keyword.
Before:
return of (a, b, c);
After:
return of(a, b, c);
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43440
llvm-svn: 325489
Currently, clang compiles explicit initializers for array
elements into series of store instructions. For large arrays of
built-in types this results in bloated output code and
significant amount of time spent on the instruction selection
phase. This patch fixes the issue by initializing such arrays
with global constants that store the binary image of the
initializer.
Differential Revision: https://reviews.llvm.org/D43181
llvm-svn: 325478
Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.
As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is to
teach clang to pass this on to the backend.
The mapping of feature support onto CPUs may not be complete; rather, it
was chosen to match LLVM's idea of which CPUs support this feature (see
lib/Target/X86/X86.td).
I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.
Reviewers: craig.topper, coby, efriedma, rsmith
Reviewed By: craig.topper
Subscribers: emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D43394
llvm-svn: 325446
Summary:
Gold plugin does not add pass to ThinLTO modules without useful symbols.
In this case ThinLTO can't create corresponding index file and some features, like CFI,
cannot be processes by backed correctly without index.
Given that we don't need the backed output we can request it to avoid
processing the module. This is implemented by this patch using new
"SkipModuleByDistributedBackend" flag.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42995
llvm-svn: 325411
Summary:
ThinLTO compilation may decide not to split module and keep at as regular LTO.
In this can this module already processed during indexing and already a part of
merged object file. So here we can just skip it.
Reviewers: pcc, tejohnson
Reviewed By: tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42680
llvm-svn: 325410
constructs.
The compiler may emit some extra warnings for functions, that are
implicit specialization of the templates, declared in the target region.
llvm-svn: 325391
This handles them exactly the same way that we handle const integral
static data members with inline definitions, which is what MSVC does.
As a follow-up, now that we have a way to mark variables inline in the
AST, we should consider marking them implicitly inline there instead of
only treating them as inline in CodeGen. Unfortunately, this breaks a
lot of dllimport test cases, so that is future work for now.
Fixes PR36125.
llvm-svn: 325375
There were a few issues previously with the target
attribute diagnostics implementation that lead to the
attribute being added to the AST despite having an error
in it.
This patch changes that, and adds a test to ensure it
does not get added to the AST.
Differential Revision: https://reviews.llvm.org/D43359
llvm-svn: 325364
This adds Sema and Codegen tests for the vcvtr builtins
(because they were missing).
Differential Revision: https://reviews.llvm.org/D43372
llvm-svn: 325351
Summary:
Fix a test failure on ARM hosts that was caused by a difference in the type of
size_t, by using a target-agnostic definiton.
Test Plan:
```
clang -cc1 -internal-isystem build/lib/clang/7.0.0/include -nostdsysteminc \
-std=c++14 -fcoroutines-ts -verify clang/test/SemaCXX/coroutines.cpp \
-fcxx-exceptions -fexceptions \
-triple armeb-none-eabi
```
llvm-svn: 325342
This broke the Chromium build, see https://crbug.com/813017
> accessibility of a class member.
>
> This fixes PR32898.
>
> rdar://problem/33737747
>
> Differential revision: https://reviews.llvm.org/D36918
llvm-svn: 325335
Assume Foo.framework with two module maps and two modules Foo and
Foo_Private.
Framework authors need to skip building both Foo and Foo_Private when
using -fmodule-name=Foo, since both are part of the framework and used
interchangeably during compilation.
rdar://problem/37500098
llvm-svn: 325305
Codegen for ordered with doacross construct might produce incorrect code
because of missing cleanup scope for the construct. Without this scope
the final runtime function call could be emitted in the wrong order that
leads to incorrect codegen.
llvm-svn: 325304
Summary:
Depends on https://reviews.llvm.org/D42605.
An implementation of the behavior described in `[dcl.fct.def.coroutine]/7`:
when a promise type overloads `operator new` using a "placement new"
that takes the same argument types as the coroutine function, that
overload is used when allocating the coroutine frame.
Simply passing references to the coroutine function parameters directly
to `operator new` results in invariant violations in LLVM's coroutine
splitting pass, so this implementation modifies Clang codegen to
produce allocator-specific alloc/store/loads for each parameter being
forwarded to the allocator.
Test Plan: `check-clang`
Reviewers: rsmith, GorNishanov, eric_niebler
Reviewed By: GorNishanov
Subscribers: lewissbaker, EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D42606
llvm-svn: 325291
Summary:
Many methods in Sema take a `bool Diagnose` parameter. Examples of such
methods include `Sema::FindDeallocationFunction` and
`Sema::SpecialMemberIsTrivial`. Calling these methods with
`Diagnose = false` allows callers to, for instance, check for the
existence of a deallocation function, without that check resulting in
error diagnostics being emitted if no matching deallocation function exists.
Add a similar `bool Diagnose` to the `Sema::FindAllocationFunctions`
method, so that checks for the existence of allocation functions can be
made without triggering error diagnostics.
This allows `SemaCoroutine.cpp`, in its implementation of the
Coroutines TS, to check for the existence of a particular `operator new`
overload, but then without error fall back to a default `operator new`
if no matching overload exists.
Test Plan: `check-clang`
Reviewers: rsmith, GorNishanov, eric_niebler
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42605
llvm-svn: 325288
Array destructors, like constructors, need to be called for each element of the
array separately. We do not have any mechanisms to do this in the analyzer,
so for now all we do is evaluate a single constructor or destructor
conservatively and give up. It automatically causes the necessary invalidation
and pointer escape for the whole array, because this is how RegionStore works.
Implement this conservative behavior for temporary destructors. This fixes the
crash on the provided test.
Differential Revision: https://reviews.llvm.org/D43149
llvm-svn: 325286
Temporary destructors fire at the end of the full-expression. It is reasonable
to attach the path note for entering/leaving the temporary destructor to its
CXXBindTemporaryExpr. This would not affect lifetime-extended temporaries with
their automatic destructors which aren't temporary destructors.
The path note may be confusing in the case of destructors after elidable copy
constructors.
Differential Revision: https://reviews.llvm.org/D43144
llvm-svn: 325284
Inline them if possible - a separate flag is added to control this.
The whole thing is under the cfg-temporary-dtors flag, off by default so far.
Temporary destructors are called at the end of full-expression. If the
temporary is lifetime-extended, automatic destructors kick in instead,
which are not addressed in this patch, and normally already work well
modulo the overally broken support for lifetime extension.
The patch operates by attaching the this-region to the CXXBindTemporaryExpr in
the program state, and then recalling it during destruction that was triggered
by that CXXBindTemporaryExpr. It has become possible because
CXXBindTemporaryExpr is part of the construction context since r325210.
Differential revision: https://reviews.llvm.org/D43104
llvm-svn: 325282
Don't look at the parent statement to figure out if the cxx-allocator-inlining
flag should kick in and prevent us from inlining the constructor within
a new-expression. We now have construction contexts for that purpose.
llvm-svn: 325278
The following test case causes issue with codegen of __enqueue_block
void (^block)(void) = ^{ callee(id, out); };
enqueue_kernel(queue, 0, ndrange, block);
Clang first does codegen for block expression in the first line and deletes its block info.
Clang then tries to do codegen for the same block expression again for the second line,
and fails because the block info is gone.
The fix is to do normal codegen for both lines. Introduce an API to OpenCL runtime to
record llvm block invoke function and llvm block literal emitted for each AST block
expression, and use the recorded information for generating the wrapper kernel.
The EmitBlockLiteral APIs are cleaned up to minimize changes to the normal codegen
of blocks.
Another minor issue is that some clean up AST expression is generated for block
with captures, which can be stripped by IgnoreImplicit.
Differential Revision: https://reviews.llvm.org/D43240
llvm-svn: 325264
Changed identifier names (especially function parameters) to not clash with type names and to follow the proper naming conventions. Use of explicit type names changed to use auto where appropriate. Removed unused parameters that should have never been added in the first place. Minor formatting cleanups.
The changes were mostly mechanical and should have no functional impact.
llvm-svn: 325256
Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us
that we're indeed constructing a temporary, so we can trivially construct a
temporary region and inline the constructor.
Much like r325202, this is only done under the off-by-default
cfg-temporary-dtors flag because the temporary destructor, even if available,
will not be inlined and won't have the correct object value (target region).
Unless this is fixed, it is quite unsafe to inline the constructor.
If the temporary is lifetime-extended, the destructor would be an automatic
destructor, which would be evaluated with a "correct" target region - modulo
the series of incorrect relocations performed during the lifetime extension.
It means that at least, values within the object are guaranteed to be properly
escaped or invalidated.
Differential Revision: https://reviews.llvm.org/D43062
llvm-svn: 325211
Constructors of C++ temporary objects that have destructors now can be queried
to discover that they're indeed constructing temporary objects.
The respective CXXBindTemporaryExpr, which is also repsonsible for destroying
the temporary at the end of full-expression, is now available at the
construction site in the CFG. This is all the context we need to provide for
temporary objects that are not lifetime extended. For lifetime-extended
temporaries, more context is necessary.
Differential Revision: https://reviews.llvm.org/D43056
llvm-svn: 325210
EvalCallOptions were introduced in r324018 for allowing various parts of
ExprEngine to notify the inlining mechanism, while preparing for evaluating a
function call, of possible difficulties with evaluating the call that they
foresee. Then mayInlineCall() would still be a single place for making the
decision.
Use that mechanism for destructors as well - pass the necessary flags from the
CFG-element-specific destructor handlers.
Part of this patch accidentally leaked into r324018, which led into a change in
tests; this change is reverted now, because even though the change looked
correct, the underlying behavior wasn't. Both of these commits were not intended
to introduce any function changes otherwise.
Differential Revision: https://reviews.llvm.org/D42991
llvm-svn: 325209
This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.
Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.
Lifetime extension for return values is still not modeled correctly.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 325202
In CFG, every DeclStmt has exactly one decl, which is always a variable.
It is also pointless to check that the initializer is the constructor because
that's how construction contexts work now.
llvm-svn: 325201
Artem Belevich