I'm currently working on including macro expansions in the Static Analyzer's
plist output, where I can only access a const SourceManager.
Differential Revision: https://reviews.llvm.org/D53940
llvm-svn: 345741
This is the first part of the implementation of the inclusion of macro
expansions into the plist output. It adds a new flag that adds a new
"macro_expansions" entry to each report that has PathDiagnosticPieces that were
expanded from a macro. While there's an entry for each macro expansion, both
the name of the macro and what it expands to is missing, and will be implemented
in followup patches.
Differential Revision: https://reviews.llvm.org/D52742
llvm-svn: 345724
Calling it too early might cause dllimport to get inherited onto the
VarDecl before the initializer got attached. See the test case for an
example where this broke things.
llvm-svn: 345709
In the course of D51340, @takuto.ikuta discovered that Clang fails to put
dllexport/import attributes on static locals during template instantiation.
For regular functions, this happens in Sema::FinalizeDeclaration(), however for
template instantiations we need to do something in or around
TemplateDeclInstantiator::VisitVarDecl(). This patch does that, and extracts
the code to a utility function.
Differential Revision: https://reviews.llvm.org/D53870
llvm-svn: 345699
A ConstantExpr class represents a full expression that's in a context where a
constant expression is required. This class reflects the path the evaluator
took to reach the expression rather than the syntactic context in which the
expression occurs.
In the future, the class will be expanded to cache the result of the evaluated
expression so that it's not needlessly re-evaluated
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D53475
llvm-svn: 345692
For arguments, pass it indirectly, since the ABI doc says pretty clearly
that arguments larger than 8 bytes are passed indirectly. This makes
va_list handling easier, anyway.
When returning, GCC returns in XMM0, and we match them.
Fixes PR39492.
llvm-svn: 345676
This is the second half of Implicit Integer Conversion Sanitizer.
It completes the first half, and finally makes the sanitizer
fully functional! Only the bitfield handling is missing.
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
void consume(unsigned int val);
void test(int val) {
consume(val);
// The 'val' is `signed int`, but `consume()` takes `unsigned int`.
// If val is negative, then consume() will be operating on a large
// unsigned value, and you may or may not have a bug.
// But yes, sometimes this is intentional.
// Making the conversion explicit silences the sanitizer.
consume((unsigned int)val);
}
```
Yes, there is a `-Wsign-conversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, likely there are cases where it does **not** warn.
The actual detection is pretty easy. We just need to check each of the values
whether it is negative, and equality-compare the results of those comparisons.
The unsigned value is obviously non-negative. Zero is non-negative too.
https://godbolt.org/g/w93oj2
We do not have to emit the check *always*, there are obvious situations
where we can avoid emitting it, since it would **always** get optimized-out.
But i do think the tautological IR (`icmp ult %x, 0`, which is always false)
should be emitted, and the middle-end should cleanup it.
This sanitizer is in the `-fsanitize=implicit-conversion` group,
and is a logical continuation of D48958 `-fsanitize=implicit-integer-truncation`.
As for the ordering, i'we opted to emit the check **after**
`-fsanitize=implicit-integer-truncation`. At least on these simple 16 test cases,
this results in 1 of the 12 emitted checks being optimized away,
as compared to 0 checks being optimized away if the order is reversed.
This is a clang part.
The compiler-rt part is D50251.
Finishes fixing [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Finishes partially fixing [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Finishes fixing https://github.com/google/sanitizers/issues/940.
Only the bitfield handling is missing.
Reviewers: vsk, rsmith, rjmccall, #sanitizers, erichkeane
Reviewed By: rsmith
Subscribers: chandlerc, filcab, cfe-commits, regehr
Tags: #sanitizers, #clang
Differential Revision: https://reviews.llvm.org/D50250
llvm-svn: 345660
We used to only define ARC keywords in -fobjc-arc mode, but now that we define
them in ObjC mode, there isn't any reason to keep them seperate.
llvm-svn: 345646
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
This allows users to specify SARIF (https://github.com/oasis-tcs/sarif-spec) as the output from the clang static analyzer so that the results can be read in by other tools, such as extensions to Visual Studio and VSCode, as well as static analyzers like CodeSonar.
llvm-svn: 345628
Added support for mapping of lambdas in the target regions. It scans all
the captures by reference in the lambda, implicitly maps those variables
in the target region and then later reinstate the addresses of
references in lambda to the correct addresses of the captured|privatized
variables.
llvm-svn: 345609
Only store the NRVO candidate if needed in ReturnStmt.
A good chuck of all of the ReturnStmt have no NRVO candidate
(more than half when parsing all of Boost). For all of them
this saves one pointer. This has no impact on children().
Differential Revision: https://reviews.llvm.org/D53716
Reviewed By: rsmith
llvm-svn: 345605
Don't store the data for the condition variable if not needed.
This cuts the size of WhileStmt by up to a pointer.
The order of the children is kept the same.
Differential Revision: https://reviews.llvm.org/D53715
Reviewed By: rjmccall
llvm-svn: 345597
Summary: So we can keep that not-so-great logic in one place.
Reviewers: rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: nemanjai, kbarton, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D53837
llvm-svn: 345594
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
llvm-svn: 345562
The existing padding checker skips classes that have any base classes.
This patch allows the checker to traverse very simple cases:
classes that have no fields and have exactly one base class.
This is important mostly in the case of array declarations.
Patch by Max Bernstein!
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D53206
llvm-svn: 345558
There are multiple reasons why field structures can be imported
in wrong order. The simplest is the ability of field initializers
and method bodies to refer fields not in order they are listed in.
Unfortunately, there is no clean solution for that currently
so I'm leaving a FIXME.
Differential Revision: https://reviews.llvm.org/D44100
llvm-svn: 345545
When using sanitizers, add <resource_dir>/<target>/lib/<sanitizer>
to the list of library paths to support using sanitized version of
runtime libraries if available.
Differential Revision: https://reviews.llvm.org/D53487
llvm-svn: 345537
being shared.
According to the standard, the variables with unspecified data-sharing
attributes in presence of `default(none)` clause must be reported to
users. Compiler did not generate error reports for the variables used in
other OpenMP regions. Patch fixes this.
llvm-svn: 345533
This has been a long time coming. Note the usage of AnalyzerOptions: I'll need
it for D52742, and added it in rC343620. The main motivation for this was that
I'll need to add yet another parameter to every single function, and some
functions would reach their 10th parameter with that change.
llvm-svn: 345531
Summary: Iteration variable must be strictly less than the number of iterations. This fixes a bug introduced by previous patch D53448.
Reviewers: ABataev, caomhin
Reviewed By: ABataev
Subscribers: guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D53827
llvm-svn: 345527
This reverts commit r345487, which reverted r345486. I think the crashes were
caused by an OOM on the builder, trying again to confirm...
llvm-svn: 345517
Don't store the data for the init statement and condition variable
if not needed. This cuts the size of SwitchStmt by up to 2 pointers.
The order of the children is intentionally kept the same.
Also use the newly available space in the bit-fields of Stmt
to store the bit representing whether all enums have been covered
instead of using a PointerIntPair.
Differential Revision: https://reviews.llvm.org/D53714
Reviewed By: rjmccall
llvm-svn: 345510
Summary: This patch adds a new code generation path for bound sharing directives containing distribute parallel for. The new code generation scheme applies to chunked schedules on distribute and parallel for directives. The scheme simplifies the code that is being generated by eliminating the need for an outer for loop over chunks for both distribute and parallel for directives. In the case of distribute it applies to any sized chunk while in the parallel for case it only applies when chunk size is 1.
Reviewers: ABataev, caomhin
Reviewed By: ABataev
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D53448
llvm-svn: 345509
Summary: This patch enables the choosing of the default schedule for parallel for loops even in non-SPMD cases.
Reviewers: ABataev, caomhin
Reviewed By: ABataev
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D53443
llvm-svn: 345507
If the loop counter is not declared in the context of the loop and it is
private, such loop counters should not be captured in the outlined
regions.
llvm-svn: 345505
Summary:
I recently discovered that adding the following code into `opencl-c.h` causes
failure of `test/Headers/opencl-c-header.cl`:
```
#pragma OPENCL EXTENSION cl_my_ext : begin
void cl_my_ext_foobarbaz();
#pragma OPENCL EXTENSIOn cl_my_ext : end
```
Clang crashes at the assertion is `ASTReader::getGlobalSubmoduleID()`:
```
assert(I != M.SubmoduleRemap.end() && "Invalid index into submodule index remap");
```
The root cause of the problem that to deserialize `OPENCL_EXTENSION_DECLS`
section `ASTReader` needs to deserialize a Decl contained in it. In turn,
deserializing a Decl requires information about whether this declaration is
part of a (sub)module, but this information is not read yet because it is
located further in a module file.
Reviewers: Anastasia, yaxunl, JDevlieghere
Reviewed By: Anastasia
Subscribers: sidorovd, cfe-commits, asavonic
Differential Revision: https://reviews.llvm.org/D53200
llvm-svn: 345497
Summary:
During method import we check for structural eq of two methods.
In the structural eq check we check for their isVirtual() flag. That
flag, however, may depend on the number of overrides. Before this
change we imported the overrides *after* we had imported the rest of the
redecl chain. So, during the import of another decl from the chain
IsVirtual() gave false result.
Writing tests for this is not really possible, because there is no way
to remove an overridden method via the AST API.
(We should access the private ASTContext::OverriddenMethods container.)
Also, we should do the remove in the middle of the import process.
Reviewers: a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53704
llvm-svn: 345496
This commit enables pushing an empty #pragma clang attribute push, then adding
multiple attributes to it, then popping them all with #pragma clang attribute
pop, just like #pragma clang diagnostic. We still support the current way of
adding these, #pragma clang attribute push(__attribute__((...))), by treating it
like a combined push/attribute. This is needed to create macros like:
DO_SOMETHING_BEGIN(attr1, attr2, attr3)
// ...
DO_SOMETHING_END
rdar://45496947
Differential revision: https://reviews.llvm.org/D53621
llvm-svn: 345486
We correctly handled extended vectors of non-floating point types.
However, we have the Intel style builtins which MSVC also supports which
do overlap in sizes with the floating point extended vectors. This
would result in overloading of floating point extended vector types
which matched sizes (e.g. <3 x float> would be backed by a <4 x float>
and thus match sizes) to be mangled similarly. Extended vectors are a
clang extension which live outside of the builtins, so mangle them all
similarly. This change just extends the current scheme to treat
floating point types similar to the way that we treat other types
currently.
This now allows the swift runtime to be built for Windows again.
llvm-svn: 345479
Don't store the data for case statements of the form LHS ... RHS if not
needed. This cuts the size of CaseStmt by 1 pointer + 1 SourceLocation in
the common case.
Also use the newly available space in the bit-fields of Stmt to store the
keyword location of SwitchCase and move the small accessor
SwitchCase::getSubStmt to the header.
Differential Revision: https://reviews.llvm.org/D53609
Reviewed By: rjmccall
llvm-svn: 345472
Only store the needed data in IfStmt. This cuts the size of IfStmt
by up to 3 pointers + 1 SourceLocation. The order of the children
is intentionally kept the same even though it would be more
convenient to put the optional trailing objects last. Additionally
use the newly available space in the bit-fields of Stmt to store
the location of the "if".
The result of this is that for the common case of an
if statement of the form:
if (some_cond)
some_statement
the size of IfStmt is brought down to 8 bytes + 2 pointers,
instead of 8 bytes + 5 pointers + 2 SourceLocation.
Differential Revision: https://reviews.llvm.org/D53607
Reviewed By: rjmccall
llvm-svn: 345464
Make the following changes to PredefinedExpr:
1. Move PredefinedExpr below StringLiteral so that it can use its definition.
2. Rename IdentType to IdentKind to be more in line with clang's conventions,
and propagate the change to its users.
3. Move the location and the IdentKind into the newly available space of
the bit-fields of Stmt.
4. Only store the function name when needed. When parsing all of Boost,
of the 1357 PredefinedExpr 919 have no function name.
Differential Revision: https://reviews.llvm.org/D53605
Reviewed By: rjmccall
llvm-svn: 345460
Although some classes are using the tail padding of Stmt, most of
them are not. In particular the expression classes are not using it
since there is Expr in between, and Expr contains a single pointer.
This patch widen the bit-fields to Stmt to 8 bytes and move some
data from NullStmt, CompoundStmt, LabelStmt, AttributedStmt, SwitchStmt,
WhileStmt, DoStmt, ForStmt, GotoStmt, ContinueStmt, BreakStmt
and ReturnStmt to the newly available space.
In itself this patch do not achieve much but I plan to go through each of
the classes in the statement/expression hierarchy and use this newly
available space. A quick estimation gives me that this should shrink the
size of the statement/expression hierarchy by >10% when parsing all of Boost.
Differential Revision: https://reviews.llvm.org/D53604
Reviewed By: rjmccall
llvm-svn: 345459
This reverts commit 8d6af840396f2da2e4ed6aab669214ae25443204 and commit
b78d19c287b6e4a9abc9fb0545de9a3106d38d3d which causes slower build times
by initializing the AddressSanitizer on every function run.
The corresponding revisions are https://reviews.llvm.org/D52814 and
https://reviews.llvm.org/D52739.
llvm-svn: 345433
Default property value 'true' preserves current behavior. Value 'false' can be
used to create VFS "root", file system that gives better control over which
files compiler can use during compilation as there are no unpredictable
accesses to real file system.
Non-fallthrough use case changes how we treat multiple VFS overlay
files. Instead of all of them being at the same level just above a real
file system, now they are nested and subsequent overlays can refer to
files in previous overlays.
Change is done both in LLVM and Clang, corresponding LLVM commit is r345431.
rdar://problem/39465552
Reviewers: bruno, benlangmuir
Reviewed By: bruno
Subscribers: dexonsmith, cfe-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D50539
llvm-svn: 345432
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof
Patch by Nicole Mazzuca!
Differential Revision: https://reviews.llvm.org/D53207
llvm-svn: 345419
Summary:
- Added names for some emitted values (such as "tobool" for
the result of a cast to boolean).
- Replaced explicit IRBuilder request for doing sext/zext/trunc
by using CreateIntCast instead.
- Simplify code for emitting satuation into one if-statement
for clamping to max, and one if-statement for clamping to min.
Reviewers: leonardchan, ebevhan
Reviewed By: leonardchan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53707
llvm-svn: 345398
The generated MS manglings differ between 32- and 64-bit, and the test only
expects the latter. See also the commit email thread.
> Thanks to Cameron DaCamara at Microsoft for letting us know what their
> chosen mangling is here!
llvm-svn: 345380
This reverts commit r345370, as it uncovered even more issues in
tests with partial/inconsistent path normalization:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13562http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/886http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20994
In particular, these tests seem to have failed:
Clang :: CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
Clang :: CodeGen/thinlto-multi-module.ll
Clang :: Driver/cuda-external-tools.cu
Clang :: Driver/cuda-options.cu
Clang :: Driver/hip-toolchain-no-rdc.hip
Clang :: Driver/hip-toolchain-rdc.hip
Clang :: Driver/openmp-offload-gpu.c
At least the Driver tests could potentially be fixed by extending
the path normalization to even more places, but the issues with the
CodeGen tests are still unknown.
In addition, a number of other tests seem to have been broken in
other clang dependent tools such as clang-tidy and clangd.
llvm-svn: 345372
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.
Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.
This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.
Compared to the previous attempt in SVN r345004, this now does
the same transformation on more paths, hopefully on the right set
of paths so that all tests pass (previously some tests failed, where
path fragments that were required to be identical turned out to
use different path separators in different places). This now also
is done only for non-windows, or cygwin/mingw targets, to preserve
all backslashes for MSVC cases (where the paths can end up e.g. embedded
into PDB files. (The transformation function itself,
llvm::sys::path::convert_to_slash only has an effect when run on windows.)
Differential Revision: https://reviews.llvm.org/D53066
llvm-svn: 345370
This corrects the leader for the swift names. The encoding for 4.2 and
5.0 differ by a single bit on the second character and were swapped.
llvm-svn: 345360
Adds support for -mno-stack-arg-probe and -mstack-probe-size.
(Not really happy copy-pasting code, but that's what we do for all the
other Windows targets.)
Differential Revision: https://reviews.llvm.org/D53617
llvm-svn: 345354
Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now).
Add two new type modifiers to NeonEmitter to handle the new prototypes.
Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the
intrinsics with the macro in arm_neon.h.
Based on a patch by Gao Yiling.
Differential Revision: https://reviews.llvm.org/D53633
llvm-svn: 345344
Nodes which have only one predecessor and only one successor can not
always be hidden, even if all states are the same.
An additional condition is needed: the predecessor may have only one successor.
This can be seen on this example:
```
A
/ \
B C
\ /
D
```
Nodes B and C can not be hidden even if all nodes in the graph have the
same state.
Differential Revision: https://reviews.llvm.org/D53735
llvm-svn: 345341
Previously, OSDynamicCast was modeled as an identity.
This is not correct: the output of OSDynamicCast may be zero even if the
input was not zero (if the class is not of desired type), and thus the
modeling led to false positives.
Instead, we are doing eager state split:
in one branch, the returned value is identical to the input parameter,
and in the other branch, the returned value is zero.
This patch required a substantial refactoring of canEval infrastructure,
as now it can return different function summaries, and not just true/false.
rdar://45497400
Differential Revision: https://reviews.llvm.org/D53624
llvm-svn: 345338
Constructing a global std::map requires clang to generate a linear
amount of code to construct the initializer list if the elements are not
constexpr-constructible. std::vector is not constexpr-constructible, so
this code pattern was generating large amounts of code.
Also, because of PR38829, LLVM is pathologically slow on large basic
blocks, and this causes slow compilation. This works around the bug and
reduces code size.
SemaChecking.cpp -debug-info-kind=limited:
time objsize
before: 1m45.023s 9.8M
after: 0m25.205s 6.9M
So, a 42% obj size reduction and 3.2x speedup.
llvm-svn: 345329
Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.
```
int main() {
int a;
auto f = [a](int a) { return a; };
}
```
results in:
```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
auto f = [a](int a) { return a; };
^
main.cpp:3:13: note: variable a is explicitly captured here
auto f = [a](int a) { return a; };
^
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53595
llvm-svn: 345308
storage class.
To be more in line with what GCC does, switch the condition to be based
on the Static Storage duration instead of the storage class.
Change-Id: I8e959d762433cda48855099353bf3c950b9d54b8
llvm-svn: 345302
Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.
This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.
The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions). This is possible, since cpu-dispatch uses '.A'
for the 'default' version.
In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.
Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284
Differential Revision: https://reviews.llvm.org/D53586
llvm-svn: 345298
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
llvm-svn: 345296
Summary:
This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`.
The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent.
As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object?
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53694
llvm-svn: 345284
Summary:
Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter.
This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53637
llvm-svn: 345283
According to the OpenMP standard, In a task generating construct, if no
default clause is present, a variable for which the data-sharing
attribute is not determined by the rules above is firstprivatized.
Compiler tries to implement this, but if the variable is not directly
used in the task context, this variable may not be firstprivatized.
Patch fixes this problem.
llvm-svn: 345277
MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope.
This avoids a compile-time crash due to confusing a member access for a constructor name.
Test case included. All tests pass.
Differential Revision: https://reviews.llvm.org/D53441
llvm-svn: 345258
Summary:
Currently clang-format breaks before the next parameter after multiline parameters (also recursively for the parent expressions of multiline parameters). However, it fails to do so for formatted multiline raw string literals:
```
$ cat test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)", 2);
}
int y = g(h(R"(multi
line)"), 2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
$ clang-format -style=google test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)",
2);
}
int y = g(h(R"(multi
line)"),
2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
```
This patch addresses this inconsistency by forcing breaking after multiline formatted raw string literals. This requires a little tweak to the indentation chosen for the contents of a formatted raw string literal: in case when that's a parameter and not the last one, the indentation is based off of the uniform indentation of all of the parameters.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52448
llvm-svn: 345242
The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to assume large vectors may be present.
llvm-svn: 345237
There is a small difference in the scope flags for C89 versus the other C/C++
dialects. This change ensures that the -Wcomma warning won't be duplicated or
issued in the wrong location. Also, the test case is refactored into C and C++
parts, with the C++ parts guarded by a #ifdef to allow the test to run in both
modes.
https://bugs.llvm.org/show_bug.cgi?id=32370
llvm-svn: 345228
Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation. This controls the language interoperability.
In particular, this is relevant for generating the CFConstantString classes
(primarily through the `__builtin___CFStringMakeConstantString` builtin) which
construct a reference to the "CFObject"'s `isa` field. This type differs
between swift 4.1 and 4.2+.
Valid values for the new option include:
- objc [default behaviour] - enable ObjectiveC interoperability
- swift-4.1 - enable interoperability with swift 4.1
- swift-4.2 - enable interoperability with swift 4.2
- swift-5.0 - enable interoperability with swift 5.0
- swift [alias] - target the latest swift ABI
Furthermore, swift 4.2+ changed the layout for the CFString when building
CoreFoundation *without* ObjectiveC interoperability. In such a case, a field
was added to the CFObject base type changing it from: <{ const int*, int }> to
<{ uintptr_t, uintptr_t, uint64_t }>.
In swift 5.0, the CFString type will be further adjusted to change the length
from a uint32_t on everything but BE LP64 targets to uint64_t.
Note that the default behaviour for clang remains unchanged and the new layout
must be explicitly opted into via `-fcf-runtime-abi=swift*`.
llvm-svn: 345222
'ignore-non-existent-contents' stopped working after r342232 in a way
that the actual attribute value isn't used and it works as if it is
always `true`.
Common use case for VFS iteration is iterating through files in umbrella
directories for modules. Ability to detect if some VFS entries point to
non-existing files is nice but non-critical. Instead of adding back
support for `'ignore-non-existent-contents': false` I am removing the
attribute, because such scenario isn't used widely enough and stricter
checks don't provide enough value to justify the maintenance.
rdar://problem/45176119
Reviewers: bruno
Reviewed By: bruno
Subscribers: hiraditya, dexonsmith, sammccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D53228
llvm-svn: 345212
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
llvm-svn: 345211
Summary:
For the following code:
```
int i;
#pragma omp taskloop
for (i = 0; i < 100; ++i)
{}
#pragma omp taskloop nogroup
for (i = 0; i < 100; ++i)
{}
```
Clang emits the following LLVM IR:
```
...
call void @__kmpc_taskgroup(%struct.ident_t* @0, i32 %0)
%2 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates*)* @.omp_task_entry. to i32 (i32, i8*)*))
...
call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %2, i32 1, i64* %8, i64* %9, i64 %13, i32 0, i32 0, i64 0, i8* null)
call void @__kmpc_end_taskgroup(%struct.ident_t* @0, i32 %0)
...
%15 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates.1*)* @.omp_task_entry..2 to i32 (i32, i8*)*))
...
call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %15, i32 1, i64* %21, i64* %22, i64 %26, i32 0, i32 0, i64 0, i8* null)
```
The first set of instructions corresponds to the first taskloop construct. It is important to note that the implicit taskgroup region associated with the taskloop construct has been materialized in our IR: the `__kmpc_taskloop` occurs inside a taskgroup region. Note also that this taskgroup region does not exist in our second taskloop because we are using the `nogroup` clause.
The issue here is the 4th argument of the kmpc_taskloop call, starting from the end, is always a zero. Checking the LLVM OpenMP RT implementation, we see that this argument corresponds to the nogroup parameter:
```
void __kmpc_taskloop(ident_t *loc, int gtid, kmp_task_t *task, int if_val,
kmp_uint64 *lb, kmp_uint64 *ub, kmp_int64 st, int nogroup,
int sched, kmp_uint64 grainsize, void *task_dup);
```
So basically we always tell to the RT to do another taskgroup region. For the first taskloop, this means that we create two taskgroup regions. For the second example, it means that despite the fact we had a nogroup clause we are going to have a taskgroup region, so we unnecessary wait until all descendant tasks have been executed.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D53636
llvm-svn: 345180
The compiler is crashing if we trying to post-capture the fields
implicitly captured inside of the task constructs. Seems, this kind of
processing is not supported and such fields should not be
firstprivatized.
llvm-svn: 345177
This will allow other generators of LLVM IR to use the auto-vectorizer
without having to change that flag.
Note: on its own, this patch will disable auto-vectorization on Hexagon
in all cases, regardless of the -fvectorize flag. There is a companion
LLVM patch that together with this one forms an NFC for clang users.
llvm-svn: 345170
This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function so that we can restrict the backend type legalizer to prevent 512-bit vectors on SKX when -mprefer-vector-width=256 is specified if no explicit 512 bit vectors were specified by the user.
This patch updates the vector width based on the argument and return types of the current function and from the types of any functions it calls. This is intended to make sure the backend type legalizer doesn't disturb any types that are required for ABI.
Differential Revision: https://reviews.llvm.org/D52441
llvm-svn: 345168
Extract the reference to the ASTContext and Triple and use them throughout the
function. This is simply a cosmetic cleanup while in the area. NFC.
llvm-svn: 345160
Unindent the body of the function by inverting check at the top. This is in
preparation for supporting CFString's new ABI with swift. NFC.
llvm-svn: 345159
Summary: New name suggestions were being used in places where existing names should have been used, this patch tries to fix some of those situations.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53191
llvm-svn: 345152
These declarations somehow survived a cleanup that combined them with the target
multiversioning functions. This patch removes them as they are no
longer necessary or used.
Change-Id: I318286401ace63bef1aa48018dabb25be0117ca0
llvm-svn: 345145
Summary:
No new tests as the existing tests for result priority should give us
coverage. Also as the new flag is trivial enough, I'm reluctant to plumb the
flag to c-index-test output.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53635
llvm-svn: 345135
Summary:
Distinguish "--autocomplete=-someflag" and "--autocomplete=-someflag,"
because the latter indicates that the user put a space before pushing tab
which should end up in a file completion.
Differential Revision: https://reviews.llvm.org/D53639
llvm-svn: 345133
Summary: Without the function body, we cannot determine is parameter was used.
Reviewers: ioeric, sammccall
Reviewed By: sammccall
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53456
llvm-svn: 345122
There was a bug that when a flag ends with '=' and no value was suggested,
clang autocompletes the flag itself.
For example, in bash, it looked like this:
```
$ clang -fmodule-file=[tab]
-> $clang -fmodule-file=-fmodule-file
```
This is not what we expect. We expect a file autocompletion when no value
was found. With this patch, pressing tab suggests files in the current
directory.
Reviewers: teemperor, ruiu
Subscribers: cfe-commits
llvm-svn: 345121
Kristof Umann