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
This patch is related to https://reviews.llvm.org/rC325081
The patch improves documentation for the attribute and removes reference to GCC
documentation.
Patch By: Elizabeth Andrews (eandrews)
Differential Revision: https://reviews.llvm.org/D43321
llvm-svn: 325186
Summary:
TypeID summaries are used by CFI and need to be serialized by ThinLTO
indexing for later use by LTO Backend.
Reviewers: tejohnson, pcc
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D42611
llvm-svn: 325182
Summary:
Frequently, a percent in protos denotes a formatting specifier for string replacement.
Thus it is desirable to keep the percent together with what follows after it.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43294
llvm-svn: 325159
Summary:
-ast-print prints omp pragmas with a trailing space. While this
behavior is likely of little concern to most users, surely it's
unintentional, and it's annoying for some source-level work I'm
pursuing. This patch focuses on omp pragmas, but it also fixes
init_seg and loop hint pragmas because they share implementation.
The testing strategy here is to add usually just one '{{$}}' per
relevant -ast-print test file. This seems to achieve good code
coverage. However, this strategy is probably easy to forget as the
tests evolve. That's probably fine as this fix is far from critical.
The main goal of the testing is to aid the initial review.
This patch also adds a fixme for "#pragma unroll", which prints as
"#pragma unroll (enable)", which is invalid syntax.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43204
llvm-svn: 325145
According to the CUDA Programming Guide this is prohibited in
whole program compilation mode. This makes sense because external
references cannot be satisfied in that mode anyway. However,
such variables are allowed in separate compilation mode which
is a valid use case.
Differential Revision: https://reviews.llvm.org/D42923
llvm-svn: 325136
This broke the Chromium build on Windows; see https://crbug.com/812231
> Fix for PR32992. Static const classes not exported.
>
> Patch by zahiraam!
>
> Differential Revision: https://reviews.llvm.org/D42968
llvm-svn: 325133
This patch fixes clang to not consider braced initializers for
aggregate elements of arrays to be potentially dependent on the
indices of the initialized elements. Resolves bug 18978:
initialize a large static array = clang oom?
https://bugs.llvm.org/show_bug.cgi?id=18978
Differential Revision: https://reviews.llvm.org/D43187
llvm-svn: 325120
Summary:
According to the C++11 standard [dcl.type.simple]p4:
The type denoted by decltype(e) is defined as follows:
- if e is an unparenthesized id-expression or an unparenthesized
class member access (5.2.5), decltype(e) is the type of the entity
named by e.
Currently Clang handles the 'member access' case incorrectly for
static data members (decltype returns T& instead of T). This patch
fixes the issue.
Reviewers: faisalv, rsmith, rogfer01
Reviewed By: rogfer01
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D42969
llvm-svn: 325117
Added support in clang for GCC function attribute 'artificial'. This attribute
is used to control stepping behavior of debugger with respect to inline
functions.
Patch By: Elizabeth Andrews (eandrews)
Differential Revision: https://reviews.llvm.org/D43259
llvm-svn: 325081
Summary:
This patch also adds the 'DW_AT_artificial' flag to the generated variable.
Addresses the issues mentioned in http://llvm.org/PR30553.
Reviewers: CarlosAlbertoEnciso, probinson, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D43189
llvm-svn: 324988
See reviews.llvm.org/M1 for evaluation, and
lists.llvm.org/pipermail/cfe-dev/2018-January/056718.html for
discussion.
Differential Revision: https://reviews.llvm.org/D42775
llvm-svn: 324956
When the current function returns a C++ object by value, CFG elements for
constructors that construct the return values can now be queried to discover
that they're indeed participating in construction of the respective return value
at the respective return statement.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 324952
Summary:
FreeBSD N64 MIPS systems can include 32-bit libraries for O32 in
/usr/lib32 similar to the 32-bit compatibility libraries provided
for FreeBSD/amd64 and FreeBSD/powerpc64.
Reviewers: dim
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D42972
llvm-svn: 324948
Summary:
CXIdxEntityRefInfo contains the member `CXIdxEntityRefKind kind;` to
differentiate implicit and direct calls. However, there are more roles
defined in SymbolRole. Among them, `Read/Write` are probably the most
useful ones as they can be used to differentiate Read/Write occurrences
of a symbol for document highlight in a text document.
See `export namespace DocumentHighlightKind`
on https://microsoft.github.io/language-server-protocol/specification
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42895
llvm-svn: 324914
Summary:
This fixes a flaw in our AST: PR27098
MSVC always gives plain enums the underlying type 'int'. Clang does this
as well, but we claim the enum is "fixed", as if the user actually wrote
': int'. It means we end up emitting spurious -Wsign-compare warnings on
code like this:
enum Vals { E1, E2, E3 };
bool f(unsigned v1, Vals v2) {
return v1 == v2;
}
We think 'v2' can take on negative values because we think 'Vals' is
fixed. This fixes that.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43110
llvm-svn: 324913
As reported here: https://bugs.llvm.org/show_bug.cgi?id=36301
The issue is that the 'use' causes the plain declaration to emit
the attributes to LLVM-IR. However, if the definition added it
later, these would silently disappear.
This commit extracts that logic to its own function in CodeGenModule,
and has the attribute-applications done during 'definition' update
the attributes properly.
Differential Revision: https://reviews.llvm.org/D43095
llvm-svn: 324907
Summary: This patch fixes a bug where the comment indent of comments in text protos gets messed up because by default paren states get created with AlignColons = true (which makes snese for ObjC).
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43194
llvm-svn: 324896
Summary:
Right now clang is skipping array cookie poisoning for any operator
new[] which is not part of the set of replaceable global allocation
functions.
This commit adds a flag to tell clang to poison all operator new[]
cookies.
A previous review was poisoning all array cookies unconditionally, but
there is an edge case which would stop working under ASan (a custom
operator new[] saves whatever pointer it returned, and then accesses
it).
This newer revision adds a command line argument to toggle this feature.
Original revision: https://reviews.llvm.org/D41301
Compiler-rt test revision with an explanation of the edge case: https://reviews.llvm.org/D41664
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43013
llvm-svn: 324884
As a first step, pass '-c/--compile-only' to ptxas so that it
doesn't complain about references to external function. This
will successfully generate object files, but they won't work
at runtime because the registration routines need to adapted.
Differential Revision: https://reviews.llvm.org/D42921
llvm-svn: 324878
Summary:
This test would fail if the python path had spaces. Add a quote around the path to fix this problem and update some test values changed by the addition of quotes around the path.
Tested on Windows and Linux with Python 3.x
Reviewers: zturner, llvm-commits
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43164
llvm-svn: 324824
This patch adds a base-class called TemplateInstantiationObserver which gets
notified whenever a template instantiation is entered or exited during
semantic analysis. This is a base class used to implement the template
profiling and debugging tool called
Templight (https://github.com/mikael-s-persson/templight).
The patch also makes a few more changes:
* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h).
* CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function).
* TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers.
* Notifications to the template-inst observer are added at the key places where templates are instantiated.
Patch by: Abel Sinkovics!
Differential Revision: https://reviews.llvm.org/D5767
llvm-svn: 324808
Massive false positives were known to be caused by continuing the analysis
after a destructor with a noreturn attribute has been executed in the program
but not modeled in the analyzer due to being missing in the CFG.
Now that work is being done on enabling the modeling of temporary constructors
and destructors in the CFG, we need to make sure that the heuristic that
suppresses these false positives keeps working when such modeling is disabled.
In particular, different code paths open up when the corresponding constructor
is being inlined during analysis.
Differential Revision: https://reviews.llvm.org/D42779
llvm-svn: 324802
It was introduced when two -analyzer-config options were added almost
simultaneously in r324793 and r324668 and the option count was not
rebased correctly in the tests.
Fixes the buildbots.
llvm-svn: 324801
The analyzer was relying on peeking the next CFG element during analysis
whenever it was trying to figure out what object is being constructed
by a given constructor. This information is now available in the current CFG
element in all cases that were previously supported by the analyzer,
so no complicated lookahead is necessary anymore.
No functional change intended - the context in the CFG should for now be
available if and only if it was previously discoverable via CFG lookahead.
Differential Revision: https://reviews.llvm.org/D42721
llvm-svn: 324800
Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.
This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in
iterator i = vector.begin();
Differential Revision: https://reviews.llvm.org/D42719
llvm-svn: 324798
CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.
CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.
Differential Revision: https://reviews.llvm.org/D42700
llvm-svn: 324796
Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.
Differential Revision: https://reviews.llvm.org/D42699
llvm-svn: 324794
This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42300
llvm-svn: 324790
This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.
Patch by Felix Kostenzer!
Differential Revision: https://reviews.llvm.org/D42745
llvm-svn: 324789
The code for going up the macro arg expansion is duplicated in many
places (and we need it for the analyzer as well, so I did not want to
duplicate it two more times).
This patch is an NFC, so the semantics should remain the same.
Differential Revision: https://reviews.llvm.org/D42458
llvm-svn: 324780
Summary:
This change avoids the overhead of storing, and later crawling,
an initializer list of all zeros for arrays. When LLVM
visits this (llvm/IR/Constants.cpp) ConstantArray::getImpl()
it will scan the list looking for an array of all zero.
We can avoid the store, and short-cut the scan, by detecting
all zeros when clang builds-up the initialization representation.
This was brought to my attention when investigating PR36030
Reviewers: majnemer, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42549
llvm-svn: 324776
LLDB creates Clang modules and had an incomplete copy of the clang
Driver code that compute the -fmodule-cache-path. This patch makes the
clang driver code accessible to LLDB.
Differential Revision: https://reviews.llvm.org/D43128
llvm-svn: 324761
Summary:
When the target object expression is short and the first selector name
is long, clang-format used to break the colon alignment:
[I performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
This happens because the colon is placed at `ContinuationIndent +
LongestObjCSelectorName`, so that any selector can be wrapped. This is
however not needed in case the longest selector is the firstone, and
not wrapped.
To overcome this, this patch does not include the first selector in
`LongestObjCSelectorName` computation (in TokenAnnotator), and lets
`ContinuationIndenter` decide how to account for the first selector
when wrapping. (Note this was already partly the case, see line 521
of ContinuationIndenter.cpp)
This way, the code gets properly aligned whenever possible without
breaking the continuation indent.
[I performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
[I // force break
performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
[I perform:@selector(loadAccessories)
withSelectorOnMainThread:true
waitUntilDone:false];
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43121
llvm-svn: 324741
Adjust the ObjC protocol conformance workaround to be more extensible.
Use a synthetic type for the protocol (`struct Protocol`). Embed this
within a reserved namespace to permit extending the extended pointer
type qualifiers similarly for ObjC lifetime qualifiers.
Introduce additional special handling for `__autoreleasing`, `__strong`,
and `__weak` Objective C lifetime qualifiers. We decorate these by
creating an artificial template type `Autoreleasing`, `Strong`, or
`Weak` in the `__ObjC` namespace. These are only considered in the
template type specialization and not the function parameter.
llvm-svn: 324701
diagnostic settings using _Pragma within a macro.
The AST writer had previously been assuming that all diagnostic state
transitions would occur within a FileID corresponding to a file. When a
diagnostic state change occured within a macro, it was unable to form a
location for that state change and would instead corrupt the diagnostic state
of the "root" node (and thus that of the main compilation).
Also introduce a "#pragma clang __debug diag_mapping" debugging utility
that I added to track this issue down.
llvm-svn: 324695
Summary:
Fixes PR36247, which is where WinEHPrepare replaces inline asm in
funclets with unreachable.
Make getBundlesForFunclet return by value to simplify some call sites.
Reviewers: smeenai, majnemer
Subscribers: eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D43033
llvm-svn: 324689
Apparently storing the pointer to a StringLiteral as
a StringRef caused this section of code to issue a ubsan
warning. This will hopefully fix that.
llvm-svn: 324687
What seems to be a bug in older versions of MSVC, constexpr
member arrays with a redefinition (to force emission) require
their initial definition to have the size between the brackets.
llvm-svn: 324682
Even though most of the inconsistencies in MallocChecker's bug categories were
fixed in r302016, one more was introduced in r301913 which was later missed.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D43074
llvm-svn: 324680
When rejecting a march= or target-cpu command line parameter,
the message is quite lacking. This patch adds a note that prints
all possible values for the current target, if the target supports it.
This adds support for the ARM/AArch64 targets (more to come!).
Differential Revision: https://reviews.llvm.org/D42978
llvm-svn: 324673
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
It makes it easier to discriminate between values of similar expressions
in different stack frames.
It also makes the separate backtrace section in ExplodedGraph dumps redundant.
Differential Revision: https://reviews.llvm.org/D42552
llvm-svn: 324660
Summary:
Concatenating Objective-C string literals inside an array literal
raises the warning -Wobjc-string-concatenation (which is enabled by default).
clang-format currently splits and concatenates string literals like
the following:
NSArray *myArray = @[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ];
into:
NSArray *myArray =
@[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaa"
@"aaaaaaaaa" ];
which raises the warning. This is https://bugs.llvm.org/show_bug.cgi?id=36153 .
The options I can think of to fix this are:
1) Have clang-format disable Wobjc-string-concatenation by emitting
pragmas around the formatted code
2) Have clang-format wrap the string literals in a macro (which
disables the warning)
3) Disable string splitting for Objective-C string literals inside
array literals
I think 1) has no precedent, and I couldn't find a good
identity() macro for 2). So, this diff implements 3).
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, stephanemoore, djasper
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42704
llvm-svn: 324618
Summary:
This patch is a fix for following issue:
https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused by front end
lowering C calling conventions without taking into account calling conventions
enforced by attribute. In this case win64cc was no correctly lowered on targets
other than Windows.
Reviewed By: rnk (Reid Kleckner)
Differential Revision: https://reviews.llvm.org/D43016
Author: belickim <mateusz.belicki@intel.com>
llvm-svn: 324594
Summary:
This patch is a follow-up to r323319 (which disables string literal breaking for
text protos) and it disables breaking before long string literals.
For example this:
```
keyyyyy: "long string literal"
```
used to get broken into:
```
keyyyyy:
"long string literal"
```
While at it, I also enabled it for LK_Proto and fixed a bug in the mustBreak code.
Reviewers: djasper, sammccall
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42957
llvm-svn: 324591
Summary:
This is split off from D42650, and sets ObjCBinPackProtocolList
to Never for the google style.
Depends On D42650
Test Plan: New tests added. make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak, stephanemoore
Reviewed By: krasimir, jolesiak, stephanemoore
Subscribers: klimek, cfe-commits, hokein, Wizard
Differential Revision: https://reviews.llvm.org/D42708
llvm-svn: 324553
When we synthesize an implicit inner initializer list when analyzing an outer
initializer list, we add it to the outer list immediately, and then fill in the
inner list. This gives the outer list no chance to update its *-dependence bits
with those of the completed inner list. To fix this, re-add the inner list to
the outer list once it's completed.
Note that we do not recompute the *-dependence bits from scratch when we
complete an outer list; this would give the wrong result for the case where a
designated initializer overwrites a dependent initializer with a non-dependent
one. The resulting list in that case should still be dependent, even though all
traces of the dependence were removed from the semantic form.
llvm-svn: 324537
The difference from the previous try is that we no longer directly
access function declarations from position independent executables. It
should work, but currently doesn't with some linkers.
It now includes a fix to not mark available_externally definitions as
dso_local.
Original message:
Start setting dso_local in clang.
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324535
typeof expressions
This commit looks through typeof type at the original expression when diagnosing
-Wsign-compare to avoid an unfriendly diagnostic.
rdar://36588828
Differential Revision: https://reviews.llvm.org/D42561
llvm-svn: 324514
This reverts commit r324500.
The bots found two failures:
ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
ThreadSanitizer-x86_64 :: pie_test.cc
when using gold. The issue is a limitation in gold when building pie
binaries. I will investigate how to work around it.
llvm-svn: 324505
It now includes a fix to not mark available_externally definitions as
dso_local.
Original message:
Start setting dso_local in clang.
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324500
I found this while looking at the ppc failures caused by the dso_local
change.
The issue was that the patch would produce the wrong answer for
available_externally. Having ForDefinition_t available in places where
the code can just check the linkage is a bit of a foot gun.
This patch removes the ForDefiniton_t argument in places where the
linkage is already know.
llvm-svn: 324499
Summary:
Currently, assertion-disabled Clang builds emit value names when generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not easily overridable. In order to get IR output containing names from a release build of Clang, the user must manually construct the CC1 invocation w/o the `-discard-value-names` option. This is less than ideal.
For example, Godbolt uses a release build of Clang, and so when asked to emit LLVM IR the result lacks names, making it harder to read. Manually invoking CC1 on Compiler Explorer is not feasible.
This patch adds the driver options `-fdiscard-value-names` and `-fno-discard-value-names` which allow the user to override the default behavior. If neither is specified, the old behavior remains.
Reviewers: erichkeane, aaron.ballman, lebedev.ri
Reviewed By: aaron.ballman
Subscribers: bogner, cfe-commits
Differential Revision: https://reviews.llvm.org/D42887
llvm-svn: 324498
This patch:
* fixes an incorrect sign-extension of unsigned values, when emitting
debug info metadata for enumerators
* the enumerators metadata is created with a flag, which determines
interpretation of the value bits (signed or unsigned)
* the enumerations metadata contains the underlying integer type and a
flag, indicating whether this is a C++ "fixed enum"
Differential Revision: https://reviews.llvm.org/D42736
llvm-svn: 324490
Summary:
Fixes formatting of ObjC message arguments when inline block is a first
argument.
Having inline block as a first argument when method has multiple parameters is
discouraged by Apple:
"It’s best practice to use only one block argument to a method. If the
method also needs other non-block arguments, the block should come last"
(https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithBlocks/WorkingwithBlocks.html#//apple_ref/doc/uid/TP40011210-CH8-SW7),
it should be correctly formatted nevertheless.
Current formatting:
```
[object blockArgument:^{
a = 42;
}
anotherArg:42];
```
Fixed (colon alignment):
```
[object
blockArgument:^{
a = 42;
}
anotherArg:42];
```
Test Plan: make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, benhamilton
Reviewed By: krasimir, benhamilton
Subscribers: benhamilton, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42493
llvm-svn: 324469
Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows.
llvm-svn: 324439
This adds the frontend support required to support the use of the
comment pragma to enable auto linking on ELFish targets. This is a
generic ELF extension supported by LLVM. We need to change the handling
for the "dependentlib" in order to accommodate the previously discussed
encoding for the dependent library descriptor. Without the custom
handling of the PCK_Lib directive, the -l prefixed option would be
encoded into the resulting object (which is treated as a frontend
error).
llvm-svn: 324438
This bit of code in the driver uses '~0U' as a sentinel value.
The result is an odd mishmash of casts just to work. This replaces
it with an optional, which is a little less crazy looking.
--ehis line, and those below, will be ignored--
M lib/Driver/Driver.cpp
llvm-svn: 324433
iteration bot.
This commit reverts r315639, which was causing clang to print
diagnostics that weren't printed before. Instead, it declares
OverrideSearch::Overridden as a SmallSetVector to fix the
non-deterministic behavior r315639 was trying to fix.
rdar://problem/36445528
llvm-svn: 324425
For input `0'e+1` lexer tokenized as numeric constant only `0'e`. Later
NumericLiteralParser skipped 0 and ' as digits and parsed `e+1` as valid
exponent going past the end of the token. Because it didn't mark numeric
literal as having an error, it continued parsing and tried to expandUCNs
with StringRef of length -2.
The fix is not to parse exponent when we reached the end of token.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588
rdar://problem/36076719
Reviewers: rsmith, t.p.northover
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple
Differential Revision: https://reviews.llvm.org/D41834
llvm-svn: 324419
Summary:
In r236412, @djasper added a comment:
// FIXME: We likely want to do this for more combinations of brackets.
// Verify that it is wanted for ObjC, too.
In D42650, @stephanemoore asked me to confirm this.
This followup to D42650 adds more tests to verify the relative
alignment behavior for Objective-C 2.0 generics passed to functions
and removes the second half of the FIXME comment.
Test Plan:
make -j12 FormatTests && \
./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*
Reviewers: stephanemoore, jolesiak, djasper
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits, djasper, stephanemoore, krasimir
Differential Revision: https://reviews.llvm.org/D42864
llvm-svn: 324364
Combined with enabled flag for stable filenames, this greatly simplifies
finding the offending report.
Differential Revision: https://reviews.llvm.org/D42831
llvm-svn: 324362
Summary:
During make check-all on Solaris, I see several instances of this warning:
clang-6.0: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
Since Solaris 10, libpthread has been folded into libc, so there's nothing to do. gcc
just ignores -pthread here. Darwin claims the option to silence the warning, and
this patch follows that lead.
Reviewers: rsmith, fedor.sergeev
Reviewed By: fedor.sergeev
Subscribers: cfe-commits, fedor.sergeev
Differential Revision: https://reviews.llvm.org/D41242
llvm-svn: 324344
Summary:
This patch adds spaces around angle brackets in text proto Google style.
Previously these were detected as template openers and closers, which happened
to have the expected effect. Now we detect them as scope openers and closers
similarly to the way braces are handled in this context.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42727
llvm-svn: 324337
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
This change reduces the live range of the loaded function pointer,
resulting in a slight code size decrease (~10KB in clang), and also
improves the security of CFI for virtual calls by making it less
likely that the function pointer will be spilled, and ensuring that
it is not spilled across a function call boundary.
Fixes PR35353.
Differential Revision: https://reviews.llvm.org/D42725
llvm-svn: 324286
The 'trivial_abi' attribute can be applied to a C++ class, struct, or
union. It makes special functions of the annotated class (the destructor
and copy/move constructors) to be trivial for the purpose of calls and,
as a result, enables the annotated class or containing classes to be
passed or returned using the C ABI for the underlying type.
When a type that is considered trivial for the purpose of calls despite
having a non-trivial destructor (which happens only when the class type
or one of its subobjects is a 'trivial_abi' class) is passed to a
function, the callee is responsible for destroying the object.
For more background, see the discussions that took place on the mailing
list:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.htmlhttp://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043
rdar://problem/35204524
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 324269
Summary:
When a preprocessor indent closes after the last line of normal code we do not
correctly fixup include guard indents. For example:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
#endif
#endif
incorrectly reformats to:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
# endif
#endif
To resolve this issue we must fixup levels after parseFile(). Delaying
the fixup introduces a new state, so consolidate include guard search
state into an enum.
Reviewers: krasimir, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42035
llvm-svn: 324246
Summary:
When a preprocessor indent closes after the last line of normal code we do not
correctly fixup include guard indents. For example:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
#endif
#endif
incorrectly reformats to:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
# endif
#endif
To resolve this issue we must fixup levels after parseFile(). Delaying
the fixup introduces a new state, so consolidate include guard search
state into an enum.
Reviewers: krasimir, klimek
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42035
llvm-svn: 324238
Previously, RISCV32TargetInfo or RISCV64TargetInfo were created
unconditionally. Use LinuxTargetInfo<RISCV??TargetInfo> to ensure that the
proper OS-specific defines are present.
This patch only adds logic to instantiate LinuxTargetInfo and leaves a TODO,
as I'm reluctant to add logic for other targets (e.g. FreeBSD, RTEMS) until
I've produced and tested at least one binary for that OS+target combo.
Thanks to @mgrang to reporting the issue.
llvm-svn: 324170
Due to Buildbot failures - most likely that's because target triples were not
specified in the tests, even though the checker behaves differently with
different target triples.
llvm-svn: 324167
This is a security check which is disabled by default but will be enabled
whenever the user consciously enables the security package. If mmap()ed memory
is both writable and executable, it makes it easier for the attacker to execute
arbitrary code when contents of this memory are compromised. Some applications
require such mmap()s though, such as different sorts of JIT.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 324166
We already suppress such reports for inlined functions, we should then
get the same behavior for macros.
The underlying reason is that the same macro, can be called from many
different contexts, and nullability can only be expected in _some_ of
them.
Assuming that the macro can return null in _all_ of them sometimes leads
to a large number of false positives.
E.g. consider the test case for the dynamic cast implementation in
macro: in such cases, the bug report is unwanted.
Tracked in rdar://36304776
Differential Revision: https://reviews.llvm.org/D42404
llvm-svn: 324161
We could in principle support such pack expansion, using techniques similar to
what we do for pack expansion of lambdas, but it's not clear it's worthwhile.
For now at least, cleanly reject these cases rather than crashing.
llvm-svn: 324160
Summary:
Clang incorrectly reports empty unions as having a unique object representation. However, this is not correct since `sizeof(EmptyUnion) == 1` AKA it has 8 bits of padding. Therefore it should be treated the same as an empty struct and report `false`.
@erichkeane also suggested this fix should be merged into the 6.0 release branch, so the initial release of `__has_unique_object_representations` is as bug-free as possible.
Reviewers: erichkeane, rsmith, aaron.ballman, majnemer
Reviewed By: erichkeane
Subscribers: cfe-commits, erichkeane
Differential Revision: https://reviews.llvm.org/D42863
llvm-svn: 324134
libprotobuf-mutator accepts protobufs with missing fields, which means
clang-proto-fuzzer does as well. clang-proto-to-cxx should match this
behavior.
llvm-svn: 324132
Summary:
This is an alternative approach to D42014 after some
investigation by stephanemoore@ and myself.
Previously, the format parameter `BinPackParameters` controlled both
C function parameter list bin-packing and Objective-C protocol conformance
list bin-packing.
We found in the Google style, some teams were changing
`BinPackParameters` from its default (`true`) to `false` so they could
lay out Objective-C protocol conformance list items one-per-line
instead of bin-packing them into as few lines as possible.
To allow teams to use one-per-line Objective-C protocol lists without
changing bin-packing for other areas like C function parameter lists,
this diff introduces a new LibFormat parameter
`ObjCBinPackProtocolList` to control the behavior just for ObjC
protocol conformance lists.
The new parameter is an enum which defaults to `Auto` to keep the
previous behavior (delegating to `BinPackParameters`).
Depends On D42649
Test Plan: New tests added. make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, stephanemoore, djasper
Reviewed By: stephanemoore
Subscribers: Wizard, hokein, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42650
llvm-svn: 324131
Summary:
Previously, Clang only emitted label names in assert builds.
However there is a CC1 option -discard-value-names that should have been used to control emission instead.
This patch removes the NDEBUG preprocessor block and instead allows LLVM to handle removing the names in accordance with the option.
Reviewers: erichkeane, aaron.ballman, majnemer
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42829
llvm-svn: 324127
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324107
When trying to track down a different bug, we discovered
that calling __builtin_va_arg on a vec3f type caused
the SROA pass to issue a warning that there was an illegal
access.
Further research showed that the vec3f type is
alloca'ed as size '12', but the _builtin_va_arg code
on x86_64 was always loading this out of registers as
{double, double}. Thus, the 2nd store into the vec3f
was storing in bytes 12-15!
This patch alters the original implementation which always
assumed {double, double} to use the actual coerced type
instead, so the LLVM-IR generated is a load/GEP/store of
a <2 x float> and a float, rather than a double and a double.
Tests were added for all combinations I could think of that
would fit in 2 FP registers, and all work exactly as expected.
Differential Revision: https://reviews.llvm.org/D42811
llvm-svn: 324098
Summary:
It should be safe, since other code paths are already generating
implicit members even in invalid CXXRecordDecls (e.g. lookup).
If we don't generate implicit members on CXXRecordDecl's completion,
they will be generated by next lookup of constructors. This causes a
crash when the following conditions are met:
- a CXXRecordDecl is invalid,
- it is provided via ExternalASTSource (e.g. from PCH),
- it has inherited constructors (they create ShadowDecls),
- lookup of its constructors was not run before ASTWriter serialized
it.
This may require the ShadowDecls created for inherited constructors to
be removed from the class, but that's no longer possible since class is
provided by ExternalASTSource.
See provided lit test for an example.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42810
llvm-svn: 324062
This fixes building Qt as shared libraries with clang in MinGW
mode; previously subclasses of the QObjectData class (in other
DLLs than the base DLL) failed to find the typeinfo symbols
(that neither were emitted in the base DLL nor in the DLL
containing the subclass).
If the virtual destructor in the newly added testcase wouldn't
be pure (or if there'd be another non-pure virtual method),
it'd be a key function and things would work out even before this
change. Make sure to locally emit the typeinfo for these classes
as well.
This matches what GCC does in this specific testcase.
This fixes the root issue that spawned PR35146. (The difference
to GCC that is initially described in that bug still is present
though.)
Differential Revision: https://reviews.llvm.org/D42641
llvm-svn: 324059
No in-tree checkers use this callback so far, hence no tests. But better fix
this now than remember to fix this when the checkers actually appear.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42785
llvm-svn: 324053
If the return statement is stored, we might as well allow querying
against it.
Also fix the bug where the return statement is not stored
if there is no return value.
This change un-merges two ExplodedNodes during call exit when the state
is otherwise identical - the CallExitBegin node itself and the "Bind
Return Value"-tagged node.
And expose the return statement through
getStatement helper function.
Differential Revision: https://reviews.llvm.org/D42130
llvm-svn: 324052
Summary:
Fix NRVO for Gro variable.
Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:
1. We were marking non-class types, such as ints, as being NRVO variables.
2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)
This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.
Reviewers: rsmith, GorNishanov, nicholas
Reviewed By: GorNishanov
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42343
llvm-svn: 324037
Indeed, "CHANGE" is not a thing yet, and we should probably not carry
around dead code which does not do anything apart from confusing the
reader.
Differential Revision: https://reviews.llvm.org/D42819
llvm-svn: 324027
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.
Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.
For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
them (i.e. array construction which we currently don't support).
Accidentally find and fix a test in which the new approach to communicating
failures produces better results.
Differential Revision: https://reviews.llvm.org/D42457
llvm-svn: 324018
DeclContext rather than injecting it wherever we happen to be.
This avoids creating functions whose DeclContext is a struct or similar.
llvm-svn: 323998
Summary:
This patch enables debugging of C99 VLA types by generating more precise
LLVM Debug metadata, using the extended DISubrange 'count' field that
takes a DIVariable.
This should implement:
Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's)
https://bugs.llvm.org/show_bug.cgi?id=30553
Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie
Reviewed By: aprantl
Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D41698
llvm-svn: 323952
This patch fixes a bug in CGRecordLowering::accumulateBitFields where it
unconditionally starts a new run and emits a storage field when it sees
a zero-sized bitfield, which causes an assertion in insertPadding to
fail when -fno-bitfield-type-align is used.
It shouldn't emit new storage if UseZeroLengthBitfieldAlignment and
UseBitFieldTypeAlignment are both false.
rdar://problem/36762205
llvm-svn: 323943
The patch ensures that a new storage unit is created when the new bitfield's
size is wider than the available bits.
rdar://36343145
Differential Revision: https://reviews.llvm.org/D42660
llvm-svn: 323921
Summary:
r312125, which introduced preprocessor indentation, shipped with a known
issue where "indentation of comments immediately before indented
preprocessor lines is toggled on each run". For example these two forms
toggle:
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
This happens because we check vertical alignment against the '#' yet
indent to the level of the 'define'. This patch resolves this issue by
aligning against the '#'.
Reviewers: krasimir, klimek, djasper
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42408
llvm-svn: 323904
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42685
llvm-svn: 323860
If the CUDA toolkit is not installed to its default locations
in /usr/local/cuda, the user is forced to specify --cuda-path.
This is tedious and the driver can be smarter if well-known tools
(like ptxas) can already be found in the PATH environment variable.
Add option --cuda-path-ignore-env if the user wants to ignore
set environment variables. Also use it in the tests to make sure
the driver always finds the same CUDA installation, regardless
of the user's environment.
Differential Revision: https://reviews.llvm.org/D42642
llvm-svn: 323848
Clang can use CUDA-9.1 now, though new APIs (are not implemented yet.
The major change is that headers in CUDA-9.1 went through substantial
changes that started in CUDA-9.0 which required substantial changes
in the cuda compatibility headers provided by clang.
There are two major issues:
* CUDA SDK no longer provides declarations for libdevice functions.
* A lot of device-side functions have become nvcc's builtins and
CUDA headers no longer contain their implementations.
This patch changes the way CUDA headers are handled if we compile
with CUDA 9.x. Both 9.0 and 9.1 are affected.
* Clang provides its own declarations of libdevice functions.
* For CUDA-9.x clang now provides implementation of device-side
'standard library' functions using libdevice.
This patch should not affect compilation with CUDA-8. There may be
some observable differences for CUDA-9.0, though they are not expected
to affect functionality.
Tested: CUDA test-suite tests for all supported combinations of:
CUDA: 7.0,7.5,8.0,9.0,9.1
GPU: sm_20, sm_35, sm_60, sm_70
Differential Revision: https://reviews.llvm.org/D42513
llvm-svn: 323713
Summary:
Fix NRVO for Gro variable.
Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:
1. We were marking non-class types, such as ints, as being NRVO variables.
2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)
This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.
Reviewers: rsmith, GorNishanov, nicholas
Reviewed By: GorNishanov
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42343
llvm-svn: 323712
Summary:
The existing unit tests in FormatTestObjC.cpp didn't fully cover
all the cases for protocol confirmance list formatting.
This extends the unit tests to more cases of protocol
conformance list formatting, especially how the behavior changes
when `BinPackParameters` changes from `true` (the default) to `false`.
Test Plan: make -j12 FormatTests && \
./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*
Reviewers: krasimir, jolesiak, stephanemoore
Reviewed By: krasimir
Subscribers: benhamilton, klimek, cfe-commits, hokein, Wizard
Differential Revision: https://reviews.llvm.org/D42649
llvm-svn: 323684
Summary:
This disables some of the most commonly used text proto delimiters and functions
for google style until we resolve several style options for that style.
In particular, wheter there should be a space surrounding braces ``msg { sub { key : value } }``
and the extent of packing of submessages on a same line.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42651
llvm-svn: 323678
Summary:
`clang-format -dump-config path/to/file.h` never passed
anything for the Code parameter to clang::format::getStyle().
This meant the logic to guess Objective-C from the contents
of a .h file never worked, because LibFormat didn't have the
code to work with.
With this fix, we now correctly read in the contents of the
file if possible with -dump-config.
I had to update the lit config for test/Format/ because
the default config ignores .h files.
Test Plan: make -j12 check-clang
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: Wizard, klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D42395
llvm-svn: 323668
Autoconf and some other systems tend to add essential compilation
options to CC (e.g. -std=gnu99). When running such an auto-generated
makefile, scan-build does not need to change CC and CXX as they are
already set to use ccc-analyzer by a configure script.
Implement a new option --keep-cc as was proposed in this discussion:
http://lists.llvm.org/pipermail/cfe-dev/2013-September/031832.html
Patch by Paul Fertser!
llvm-svn: 323665
clang's -x option doesn't accept c-cpp-output as a language (even though
463eb6ab was merged, the driver still doesn't handle that).
This bug prevents testing C language projects when ccache is used.
Fixes#25851.
Investigation and patch by Dave Rigby.
llvm-svn: 323664
Summary:
This change is step three in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API.
Step 4) Update Polly to use the new IRBuilder API.
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment()
and getSourceAlignment() instead.
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
Reviewers: rjmccall
Subscribers: jyknight, nemanjai, nhaehnle, javed.absar, sbc100, aheejin, kbarton, fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D41677
llvm-svn: 323617
Clang supports compiling CUDA source files for some time,
format them by default as well.
Differential Revision: https://reviews.llvm.org/D42589
llvm-svn: 323615
constructor.
Previously, clang would emit an over-aligned (16-byte) store to
initialize B::x in B's base constructor when compiling the following
code:
struct A {
__attribute__((aligned(16))) double data1;
};
struct B : public virtual A {
B() : x(123) {}
double a;
int x;
};
struct C : public virtual B {};
void test() { B b; C c; }
This was happening because the code in IRGen that does member
initialization was using the alignment of a complete object instead of
the non-virtual alignment.
This commit fixes the bug.
rdar://problem/36382481
Differential Revision: https://reviews.llvm.org/D42521
llvm-svn: 323578
Summary:
Both MS and PS4 targets are capable of recognizing the
existence of: #pragma region, #pragma endregion.
Since this pragma is only a hint for certain editors, and has no logic,
it seems helpful to permit this pragma in all cases, not just MS compatibility mode.
Reviewers: rnk, rsmith, majnemer
Reviewed By: majnemer
Subscribers: Quuxplusone, probinson, majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42248
llvm-svn: 323577
TemplateTemplateParmDecls of alias templates ended-up serialized as 'file-level decls' which was causing a crash while trying to index a PCH/module file that contained them.
Commit makes sure TemplateTemplateParmDecls are not recorded as such kind of decls.
Fixes crash of rdar://36608297
Differential Revision: https://reviews.llvm.org/D42588
llvm-svn: 323549
Add support for mangling ObjC protocol conformances in MS ABI as if they are
COM interfaces. By diverging from the itanium mangling of `objc_protocol`
prefixed names, this approach allows for a semi-reasonable, albeit of
questionable sanity, undecoration via existing tooling. There is also the
possibility of adding an extension and taking part of the namespace to add the
conformance via the `L` and `Z` "modifiers", but the existing tooling would not
be able to properly undecorated the symbol even though incidentally `undname`
currently produces something legible while wine's implementation is not able to
cope with the extension.
This allows for the disambiguation of overloads where the parameter differs
only in the protocol conformance of the ObjC type, e.g.
```
@protocol P;
void f(std::vector<id>);
void f(std::vector<id<P>>);
```
which clang would previously fail due to the mangling being identical as the
protocol conformance was ignored.
llvm-svn: 323547
Summary:
JavaScript automatic semicolon insertion can trigger before [ and (, so
avoid breaking before them if the previous token is likely to terminate
an expression.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42570
llvm-svn: 323532
We can stash the cached transparent tag bit in existing pointer padding.
Everything coming out of ASTContext is always aligned to a multiple of
8, so we have 8 spare bits.
llvm-svn: 323528
Summary:
For OpenCL 1.1 embedded profile 64 bit integers i.e. long,
ulong including the appropriate vector data types and operations
on 64-bit integers are optional. The "cles_khr_int64" extension
string will be reported if the embedded profile implementation
supports 64-bit integers.
Reviewers: Anastasia, bader
Reviewed By: Anastasia, bader
Subscribers: bader, yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D42532
llvm-svn: 323522
Also, a number of style and bug fixes was done:
* ASTImporterTest: added sanity check for source node
* ExternalASTMerger: better lookup for template specializations
* ASTImporter: don't add templated declarations into DeclContext
* ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations
* ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc
Differential Revision: https://reviews.llvm.org/D42301
llvm-svn: 323519
For /arch:AVX512F:
clang-cl and cl.exe both defines __AVX512F__ __AVX512CD__.
clang-cl also defines __AVX512ER__ __AVX512PF__.
64-bit cl.exe also defines (according to /Bz) _NO_PREFETCHW.
For /arch:AVX512:
clang-cl and cl.exe both define
__AVX512F__ __AVX512CD__ __AVX512BW__ __AVX512DQ__ __AVX512VL__.
64-bit cl.exe also defines _NO_PREFETCHW.
So not 100% identical, but pretty close.
Also refactor the existing AVX / AVX2 code to not repeat itself in both the
32-bit and 64-bit cases.
https://reviews.llvm.org/D42538
llvm-svn: 323433
r213083 initially implemented /arch: support by mapping it to CPU features.
Then r241077 additionally mapped it to CPU, which made the feature flags
redundant (if harmless). This change here removes the redundant mapping to
feature flags, and rewrites test/Driver/cl-x86-flags.c to be a bit more of an
integration test that checks for preprocessor defines like AVX (like documented
on MSDN) instead of for driver flags.
To keep emitting warn_drv_unused_argument, use getLastArgNoClaim() followed by an explicit claim() if needed.
This is in preparation for adding support for /arch:AVX512(F).
No intended behavior change.
https://reviews.llvm.org/D42497
llvm-svn: 323426
Summary:
Consider the text proto:
```
message {
sub { key: value }
}
```
Previously the first `{` was TT_Unknown, which caused the inner message to be
indented by the continuation width. This didn't happen for:
```
message {
sub: { key: value }
}
```
This is because the code to mark the first `{` as a TT_DictLiteral was only
considering the case where it marches forward and reaches a `:`.
This patch updates this by looking not only for `:`, but also for `<` and `{`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42500
llvm-svn: 323419
r317337 missed that scudo is supported on MIPS32, so permit that option for
MIPS32.
Reviewers: cryptoad, atanasyan
Differential Revision: https://reviews.llvm.org/D42416
llvm-svn: 323412
Do not attempt to get the pointee of void* while generating a bug report
(otherwise it will trigger an assert inside RegionStoreManager::getBinding
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42396
llvm-svn: 323382
Summary:
Use corutine function arguments to initialize a promise type, but only
if the promise type defines a constructor that takes those arguments.
Otherwise, fall back to the default constructor.
Test Plan: check-clang
Reviewers: rsmith, GorNishanov, eric_niebler
Reviewed By: GorNishanov
Subscribers: toby-allsopp, lewissbaker, EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D41820
llvm-svn: 323381
In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.
Differential Revision: https://reviews.llvm.org/D42221
llvm-svn: 323376
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.
Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.
Differential Revision: https://reviews.llvm.org/D42192
llvm-svn: 323370
The MSVC runtime library does not provide a definition of wmemcmp,
so we need an inline implementation.
Differential Revision: https://reviews.llvm.org/D42441
llvm-svn: 323362
Hidden visibility is almost the opposite of dllimport. We were
producing them before (dllimport wins in the existing llvm
implementation), but now the llvm verifier produces an error.
llvm-svn: 323361
NVPTX does not have runtime support necessary for profiling to work
and even call arc collection is prohibitively expensive. Furthermore,
there's no easy way to collect the samples. NVPTX also does not
support global constructors that clang generates if sample/arc collection
is enabled.
Differential Revision: https://reviews.llvm.org/D42452
llvm-svn: 323345
Summary:
Commonly string literals in protos are already multiline, so breaking them
further is undesirable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42373
llvm-svn: 323319
Summary:
The new test is now in the right directory with the other ASTVisitor tests and uses
now the provided TestVisitor framework.
Subscribers: hintonda, v.g.vassilev, klimek, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37557
llvm-svn: 323310
- Test needs to be able to handle "clang.exe" on Windows
- Test needs to be able to handle either '/' or '\\' used as the path separator
Reviewed by Paul Robinson
llvm-svn: 323285
This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
So in this patch MaxAtomicInlineWidth is reset as follows:
For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
Differential Revision: https://reviews.llvm.org/D42154
llvm-svn: 323281
We would previously treat `SEL` as a pointer-only type. This is not the
case. It should be treated similarly to `id` and `Class`. Add some
test cases to ensure that it will be properly handled as well.
llvm-svn: 323257
These symbols are supposed to be preserved even by the linker. Use the
`llvm.used` to ensure that the symbols are not removed by DCE in the
linker. This should be a no-op change on MachO since the symbols are
annotated as `no_dead_strip`.
llvm-svn: 323247
Analyzing problems which appear in scan-build results can be very
difficult, as after the launch no exact invocation is stored, and it's
super-hard to launch the debugger.
With this patch, the exact analyzer invocation appears in the footer,
and can be copied to debug/check reproducibility/etc.
rdar://35980230
llvm-svn: 323245
Rather than hardcode the pointerness of the `id` and `class` types,
handle them generically. This allows for the template type
specialization of `remove_pointer<id>` which would look through the `id`
type and deal with the `objc_object` structure without the pointer.
llvm-svn: 323241
We should (almost) never consider a device-side declaration to match a
library builtin functio. Otherwise clang may ignore the implementation
provided by the CUDA headers and emit clang's idea of the builtin.
Differential Revision: https://reviews.llvm.org/D42319
llvm-svn: 323239
The tests are targeting Windows but do not specify an environment. When
executed on Linux, they would use an ELF output rather than the COFF
output. Explicitly provide an environment.
llvm-svn: 323225
Summary:
The parameter overrides the underlying vfs used by ClangTool for
filesystem operations.
Patch by Vladimir Plyashkun.
Reviewers: alexfh, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41947
llvm-svn: 323195
Summary:
This patch is meant to address the last outstanding review comment on the already approved
(but not yet commited) https://reviews.llvm.org/D35755, namely making the handling of the RHEL
devtoolsets Linux-specific.
Don't know if it's best integrated into the former or applied subsequently.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Reviewers: fedor.sergeev, tstellar, jyknight
Reviewed By: fedor.sergeev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42029
llvm-svn: 323194
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
Summary:
This patch fixes an issue where the UnbreakableTailLength would be counted towards
the length of a token during breaking, even though we can break after the token.
For example, this proto text with column limit 20
```
# ColumnLimit: 20 V
foo: {
bar: {
bazoo: "aaaaaaa"
}
}
```
was broken:
```
# ColumnLimit: 20 V
foo: {
bar: {
bazoo:
"aaaaaaa"
}
}
```
because the 2 closing `}` were counted towards the string literal's `UnbreakableTailLength`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42376
llvm-svn: 323188
Pass and return _Float16 as if it were an int or float for ARM, but with the
top 16 bits unspecified, similarly like we already do for __fp16.
We will implement proper half-precision function argument lowering in the ARM
backend soon, but want to use this workaround in the mean time.
Differential Revision: https://reviews.llvm.org/D42318
llvm-svn: 323185
When a function taking transparent union is declared as taking one of
union members earlier in the translation unit, clang would hit an
"Invalid cast" assertion during EmitFunctionProlog. This case
corresponds to function f1 in test/CodeGen/transparent-union-redecl.c.
We decided to cast i32 to union because after merging function
declarations function parameter type becomes int,
CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide
it is a trivial case. But these types should also be castable to
parameter declaration type which is not the case here.
Now the fix is in converting from ABIArgInfo type to VarDecl type and using
argument demotion when necessary.
Additional tests in Sema/transparent-union.c capture current behavior and make
sure there are no regressions.
rdar://problem/34949329
Reviewers: rjmccall, rafael
Reviewed By: rjmccall
Subscribers: aemerson, cfe-commits, kristof.beyls, ahatanak
Differential Revision: https://reviews.llvm.org/D41311
llvm-svn: 323156
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
The check (inside StackHintGeneratorForSymbol::getMessage)
if (!N)
return getMessageForSymbolNotFound()
is moved to the beginning of the function.
Differential revision: https://reviews.llvm.org/D42388
Test plan: make check-all
llvm-svn: 323146
Summary:
This patch removes IdentifierInfo from completion token after remembering
the identifier in the preprocessor.
Prior to this patch, completion token had the IdentifierInfo set to null when
completing at the start of identifier and to the II for completion prefix
when in the middle of identifier.
This patch unifies how code completion token is handled when it is insterted
before the identifier and in the middle of the identifier.
The actual IdentifierInfo can still be obtained from the Preprocessor.
Reviewers: bkramer, arphaman
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42241
llvm-svn: 323133
Summary:
The MultiplexExternalSemaSource doesn't correctly overload the `getModule` function,
causing the multiplexer to not forward this call as intended.
Reviewers: v.g.vassilev
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39416
llvm-svn: 323122
Fix an assertion failure caused by a missing CheckName. The malloc checker
enables "basic" support in the CStringChecker, which causes some CString
bounds checks to be enabled. In this case, make sure that we have a
valid CheckName for the BugType.
llvm-svn: 323052
Summary:
kvm - kernel memory interface
The kvm(3) functions like kvm_open(), kvm_getargv() or kvm_getenvv()
are used in programs that can request information about a kernel and
its processes. The LLVM sanitizers will make use of them on NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, dvyukov
Reviewed By: vitalybuka
Subscribers: llvm-commits, cfe-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D42017
llvm-svn: 323022
This fixes PR32732 by updating CurLexerKind to reflect available lexers.
We were hitting null pointer in Preprocessor::Lex because CurLexerKind
was CLK_Lexer but CurLexer was null. And we set it to null in
Preprocessor::HandleEndOfFile when exiting a file with code completion
point.
To reproduce the crash it is important for a comment to be inside a
class specifier. In this case in Parser::ParseClassSpecifier we improve
error recovery by pushing a semicolon token back into the preprocessor
and later on try to lex a token because we haven't reached the end of
file.
Also clang crashes only on code completion in included file, i.e. when
IncludeMacroStack is not empty. Though we reset CurLexer even if include
stack is empty. The difference is that during pushing back a semicolon
token, preprocessor calls EnterCachingLexMode which decides it is
already in caching mode because various lexers are null and
IncludeMacroStack is not empty. As the result, CurLexerKind remains
CLK_Lexer instead of updating to CLK_CachingLexer.
rdar://problem/34787685
Reviewers: akyrtzi, doug.gregor, arphaman
Reviewed By: arphaman
Subscribers: cfe-commits, kfunk, arphaman, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D41688
llvm-svn: 323008
Using a BlockDecl in a default member initializer causes it to be attached to
CXXMethodDecl without its access specifier being set. This prevents a crash
where getAccess is called on this BlockDecl, since that method expects any
Decl in CXXRecord scope to have an access specifier.
llvm-svn: 322984
Summary:
When setting CMAKE_ASM_COMPILER=clang, we also need to set
CMAKE_ASM_COMPILER_ID=Clang.
This is needed because cmake won't set CMAKE_ASM_COMPILER_ID if
CMAKE_ASM_COMPILER is already set.
Without CMAKE_ASM_COMPILER_ID, cmake can't set
CMAKE_ASM_COMPILER_OPTIONS_TARGET either, which means
CMAKE_ASM_COMPILER_TARGET is ignored, causing cross compiling to fail,
i.e., `--target=${CMAKE_ASM_COMPILER_TARGET}` isn't passed.
Differential Revision: https://reviews.llvm.org/D42232
llvm-svn: 322977
Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
llvm-svn: 322964
Summary:
This patch adds canonical delimiter support to the raw string formatting.
This allows matching delimiters to be updated to the canonical one.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42187
llvm-svn: 322956
Summary:
This patch addresses bug 36002, where a combination of options causes the line
following a short block in macro to be merged with that macro.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42298
llvm-svn: 322954
The standard says:
[expr.static.cast] p11: "If the prvalue of type “pointer to cv1 B” points to a B
that is actually a subobject of an object of type D, the resulting pointer points
to the enclosing object of type D. Otherwise, the behavior is undefined."
Therefore, the GEP must be inbounds.
This should solve the failure to optimize away a null check shown in PR35909:
https://bugs.llvm.org/show_bug.cgi?id=35909
Differential Revision: https://reviews.llvm.org/D42249
llvm-svn: 322950
This removes the following (already default-off) warnings from -Wextra:
-Wtautological-type-limit-compare,
-Wtautological-unsigned-zero-compare
-Wtautological-unsigned-enum-zero-compare
On the thread "[cfe-dev] -Wtautological-constant-compare issues", clang
code owners Richard Smith, John McCall, and Reid Kleckner as well as
libc++ code owner Marshall Clow stated that these new warnings are not
yet ready for prime time and shouldn't be part of -Wextra.
Furthermore, Vedant Kumar (Apple), Peter Hosek (Fuchsia), and me (Chromium)
expressed the same concerns (Vedant on that thread, Peter on
https://reviews.llvm.org/D39462, me on https://reviews.llvm.org/D41512).
So remove them from -Wextra, and remove TautologicalInRangeCompare from
TautologicalCompare too until they're usable with real-world code.
llvm-svn: 322901
Summary:
The Google style guide is neutral on whether there should be a
space before the protocol list in an Objective-C @interface or
@implementation.
The majority of Objective-C code in both Apple's public
header files and Google's open-source uses a space before
the protocol list, so this changes the google style to
default ObjCSpaceBeforeProtocolList to true.
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41074
llvm-svn: 322873
Firstly, each offloading entry must have a unique name or the
linker will complain if there are multiple files with target
regions. Secondly, the compiler must not introduce padding so
mark the struct with a PackedAttr.
Differential Revision: https://reviews.llvm.org/D42168
llvm-svn: 322858
Summary:
The new method 'OverridePreamble' allows to override the preamble of
any source file without checking if preamble bounds or dependencies
were changed.
This is used for completion in clangd.
Reviewers: bkramer, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41990
llvm-svn: 322853
The dump function for Scope only has 20 out of the 24 flags. Since it looped
until no flags were left, having an unknown flag lead to an infinite loop.
That loop has been changed to a single pass for each flag, plus an assert to
alert if new flags are added.
llvm-svn: 322813
MemRegion::getString() is a wrapper around MemRegion::dump(), which is not
user-friendly and should never be used for diagnostic messages.
Actual cases where raw dumps were reaching the user were unintentionally fixed
in r315736; these were noticed accidentally and shouldn't be reproducible
anymore. For now RetainCountChecker only tracks pointers through variable
regions, and for those dumps are "fine". However, we should still use a less
dangerous method for producing our path notes.
This patch replaces the dump with printing a variable name, asserting that this
is indeed a variable.
Differential Revision: https://reviews.llvm.org/D42015
llvm-svn: 322799
PreStmt<CXXNewExpr> was never called.
Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was
called twice when the allocator was inlined: once after evaluating the
new-expression itself, once after evaluating the allocator call which, for the
lack of better options, uses the new-expression as the call site.
This patch fixes both problems.
Differential Revision: https://reviews.llvm.org/D41934
rdar://problem/12180598
llvm-svn: 322797
Add PostAllocatorCall program point to represent the moment in the analysis
between the operator new() call and the constructor call. Pointer cast from
"void *" to the correct object pointer type has already happened by this point.
The new program point, unlike the previously used PostImplicitCall, contains a
reference to the new-expression, which allows adding path diagnostics over it.
Differential Revision: https://reviews.llvm.org/D41800
rdar://problem/12180598
llvm-svn: 322796
Pointer escape event notifies checkers that a pointer can no longer be reliably
tracked by the analyzer. For example, if a pointer is passed into a function
that has no body available, or written into a global, MallocChecker would
no longer report memory leaks for such pointer.
In case of operator new() under -analyzer-config c++-allocator-inlining=true,
MallocChecker would start tracking the pointer allocated by operator new()
only to immediately meet a pointer escape event notifying the checker that the
pointer has escaped into a constructor (assuming that the body of the
constructor is not available) and immediately stop tracking it. Even though
it is theoretically possible for such constructor to put "this" into
a global container that would later be freed, we prefer to preserve the old
behavior of MallocChecker, i.e. a memory leak warning, in order to
be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining
*reduces* the amount of false positives coming from this-pointers escaping in
constructors, because it'd be able to inline constructors in some cases.
With other checkers working similarly, we simply suppress the escape event for
this-value of the constructor, regardless of analyzer options.
Differential Revision: https://reviews.llvm.org/D41797
rdar://problem/12180598
llvm-svn: 322795
Implements finding appropriate source locations for intermediate diagnostic
pieces in path-sensitive bug reports that need to descend into an inlined
operator new() call that was called via new-expression. The diagnostics have
worked correctly when operator new() was called "directly".
Differential Revision: https://reviews.llvm.org/D41409
rdar://problem/12180598
llvm-svn: 322791
Fix the const qualifier so that the operator defined in the tests indeed does
override the default global nothrow version of new.
Differential Revision: https://reviews.llvm.org/D41408
llvm-svn: 322790
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.
Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.
Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598
llvm-svn: 322787
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.
Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.
Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598
llvm-svn: 322780
- Fix inaccurate instruction listings.
- Fix small issues in _mm_getcsr and _mm_setcsr.
- Fix description of NaN handling in comparison intrinsics.
- Fix inaccurate description of _mm_movemask_pi8.
- Fix inaccurate instruction mappings.
- Fix typos.
- Clarify wording on some descriptions.
- Fix bit ranges in return value.
- Fix typo in _mm_move_ms intrinsic instruction since it operates on singe-precision values, not double.
- This patch was made by Craig Flores
Differential Revision: https://reviews.llvm.org/D41523
llvm-svn: 322778
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".
Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.
The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.
Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598
llvm-svn: 322777
Represent the symbolic value for results of pointer arithmetic on void pointers
in a different way: instead of making void-typed element regions, make
char-typed element regions.
Add an assertion that ensures that no void-typed regions are ever constructed.
This is a refactoring of internals that should not immediately affect
the analyzer's (default) behavior.
Differential Revision: https://reviews.llvm.org/D40939
llvm-svn: 322775
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.
However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.
Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.
Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.
Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598
llvm-svn: 322774
When using -fno-integrated-as flag, the gnu assembler produces code
with some default march/mabi which later causes linker failure due
to incompatible mabi/march.
In this patch we explicitly propagate -mabi and -march flags to the
GNU assembler.
In this patch we explicitly propagate -mabi and -march flags to the GNU assembler.
Differential Revision: https://reviews.llvm.org/D41271
llvm-svn: 322769
In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and also opens up more surface area for bugs if an
inconsistent location context is used.
This patch introduces a helper on an exploded node, and ensures
consistent usage of either `ExplodedNode::getSVal` or
`CheckContext::getSVal` across the codebase.
As a result, a large number of redundant lines is removed.
Differential Revision: https://reviews.llvm.org/D42155
llvm-svn: 322753
All usages of isSubRegionOf separately check for reflexive case, and in
any case, set theory tells us that each set is a subset of itself.
Differential Revision: https://reviews.llvm.org/D42140
llvm-svn: 322752
Summary: This replaces an unordered_set from r322690 with an array and binary search.
Reviewers: bkramer, benhamilton
Reviewed By: bkramer, benhamilton
Subscribers: jolesiak, benhamilton, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42189
llvm-svn: 322749
Both are related to handling anonymous structures.
* clang didn't handle () around an anonymous struct variable.
* clang also crashed on syntax errors that could lead to other
syntactic constructs following the declaration of an
anonymous struct. While the code is invalid, that's not
a good reason to panic compiler.
Differential Revision: https://reviews.llvm.org/D41788
llvm-svn: 322742
When parsing C++ type construction expressions with list initialization,
forward the locations of the braces to Sema.
Without these locations, the code coverage pass crashes on the given test
case, because the pass relies on getLocEnd() returning a valid location.
Here is what this patch does in more detail:
- Forwards init-list brace locations to Sema (ParseExprCXX),
- Builds an InitializationKind with these locations (SemaExprCXX), and
- Uses these locations for constructor initialization (SemaInit).
The remaining changes fall out of introducing a new overload for
creating direct-list InitializationKinds.
Testing: check-clang, and a stage2 coverage-enabled build of clang with
asserts enabled.
Differential Revision: https://reviews.llvm.org/D41921
llvm-svn: 322729
Summary:
As result deduplication or reduction is not supported in the framework,
we should leave the deplication to tools (if needed) until the framework supports it.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42111
llvm-svn: 322691
Summary:
This improves upon the previous Objective-C header guessing heuristic
from rC320479.
Now, we run the lexer on C++ header files and look for Objective-C
keywords and syntax. We also look for Foundation types.
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42135
llvm-svn: 322690
Summary:
This would allow code completion clients to know which context is visited during Sema code completion.
Also some changes:
* add `EnteredContext` callback in VisibleDeclConsumer.
* add a simple unittest for sema code completion (only for visited contexts at the moment).
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, bkramer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42071
llvm-svn: 322661
Summary:
This patch changes the structure for raw string formatting options by making it
language based (enumerate delimiters per language) as opposed to delimiter-based
(specify the language for a delimiter). The raw string formatting now uses an
appropriate style from the .clang-format file, if exists.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42098
llvm-svn: 322634
HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
parallel for simd` directives.
Added codegen for `depend` clauses on `#pragma omp target teams
distribute parallel for simd` directives.
llvm-svn: 322587
Summary:
noload_lookups() was too lazy: in addition to avoiding external decls, it
avoided populating the lazy lookup structure for internal decls.
This is the right behavior for the existing callsite in ASTDumper, but I think
it's not a very useful default, so we populate it by default.
While here:
- remove an unused test file accidentally added in r322371.
- remove lookups_begin()/lookups_end() in favor of lookups().begin(), which is
more common and more efficient.
Reviewers: ilya-biryukov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D42077
llvm-svn: 322548
Summary:
Introduce clang_getCursorPrettyPrinted() for pretty printing
declarations. Expose also PrintingPolicy, so the user gets more
fine-grained control of the entities being printed.
The already existing clang_getCursorDisplayName() is pretty limited -
for example, it does not handle return types, parameter names or default
arguments for function declarations. Addressing these issues in
clang_getCursorDisplayName() would mean to duplicate existing code
(e.g. clang::DeclPrinter), so rather expose new API to access the
existing functionality.
Reviewed By: jbcoe
Subscribers: cfe-commits
Tags: #clang
Patch by nik (Nikolai Kosjar)
Differential Revision: https://reviews.llvm.org/D39903
llvm-svn: 322540
We were trying to emit a diag::err_bad_multiversion_option diagnostic,
which expects an int as its first argument, with a string argument. As
it happens, the string `Feature` that was causing this was shadowing an
int `Feature` from the surrounding scope. :)
llvm-svn: 322530
Summary:
There are only two valid integrated Clang driver tools: `-cc1` and
`-cc1as`. If a user asks for an unknown tool, such as `-cc1asphalt`,
an error message is displayed to indicate that there is no such tool,
but the message doesn't indicate what the valid options are.
Include the valid options in the error message.
Test Plan: `check-clang`
Reviewers: sepavloff, bkramer, phosek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42004
llvm-svn: 322517
simd`.
Added host codegen + codegen for devices with default codegen for
`#pragma omp target teams distribute parallel for simd` directive.
llvm-svn: 322515
Thanks to Eli Friedman, who suggested the reason these tests failed on a few
buildbots yet works fine locally is because non-assert builds don't emit value
labels.
llvm-svn: 322514
The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit.
Differential Revision: https://reviews.llvm.org/D20124
llvm-svn: 322503
RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64.
Unfortunately we need to count argument registers in the frontend in order to
determine when to emit signext and zeroext attributes. Integer scalars are
extended according to their type up to 32-bits and then sign-extended to XLen
when passed in registers, but are anyext when passed on the stack. This patch
only implements the base integer (soft float) ABIs.
For more information on the RISC-V ABI, see [the ABI
doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md),
my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and
the [LLVM RISC-V calling convention
patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment
documenting frontend expectations).
Differential Revision: https://reviews.llvm.org/D40023
llvm-svn: 322494
Summary:
This patch adds a FormatStyleSet for storing per-language FormatStyles for the
purposes of formatting code blocks inside the main code.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, djasper, bkramer, cfe-commits
Differential Revision: https://reviews.llvm.org/D41487
llvm-svn: 322479
Summary:
kunpck intrinsics were removed in favor of native IR a few months ago. The implementation lowers them as by operation on the integer types passed to the intrinsic and then just shifting, masking, and oring them together. A special X86 DAG combine was added to recognize this patter and turn it into a concat_vector operation.
I think it makes more sense to keep the IR implementation closer to vector operations on vXi1. Given that we expect these builtins to be used around other builtins that operate on k-registers which we try to represent in IR with vXi1. InstCombine should be able to get rid of the bitcasts between integers and vXi1 leaving only the vector operations.
Reviewers: RKSimon, spatel, zvi, jina.nahias
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42016
llvm-svn: 322461
Summary:
Use monospace for option flags in the PCH section, instead of the
italics that were being used previously.
I believe these used to be links, for which single backticks would
have been appropriate, but since they were un-link-ified in
https://reviews.llvm.org/rL275560, I believe monospace is now more
appropriate, and so two backticks are needed.
Test Plan:
Build the `docs-clang-html` target and confirm the options are rendered
using monospace font.
Reviewers: sepavloff, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42005
llvm-svn: 322447
Krasimir Georgiev