Summary:
The LTO Config field wasn't being set when invoking a ThinLTO backend
via clang (i.e. for distributed builds).
Reviewers: danielcdh
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39923
llvm-svn: 317951
Summary:
[OpenMP] diagnose assign to firstprivate const
Clang does not diagnose assignments to const variables declared
firstprivate. Furthermore, codegen is broken such that, at run time,
such assignments simply have no effect. For example, the following
prints 0 not 1:
int main() {
const int i = 0;
#pragma omp parallel firstprivate(i)
{ i=1; printf("%d\n", i); }
return 0;
}
This commit makes these assignments a compile error, which is
consistent with other OpenMP compilers I've tried (pgcc 17.4-0, gcc
6.3.0).
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39859
llvm-svn: 317891
Summary: This patch adds support for python-style comments in text protos.
Reviewers: djasper
Reviewed By: djasper
Subscribers: bkramer, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39806
llvm-svn: 317886
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
llvm-svn: 317875
The backend should be able to combine the negates to create fmsub, fnmadd, and fnmsub. faddsub converting to fsubadd still needs work I think, but should be very doable.
This matches what we already do for the masked builtins.
This only covers the packed builtins. Scalar builtins will be done after FMA4 is fixed.
llvm-svn: 317873
Summary:
This is basically reverting r261774 with a tweak for clang-cl. UNIX
standard states:
When c99 encounters a compilation error that causes an object file not
to be created, it shall write a diagnostic to standard error and
continue to compile other source code operands, but it shall not perform
the link phase and it shall return a non-zero exit status
The same goes for c89 or cc. And they are all alias or shims pointing to
clang on Darwin.
The original commit was intended for CUDA so the error message doesn't
get emit twice for both host and device. It seems that the clang driver
has been changed to model the CUDA dependency differently. Now the
driver behaves the same without this commit.
rdar://problem/32223263
Reviewers: thakis, dexonsmith, tra
Reviewed By: tra
Subscribers: jlebar, cfe-commits
Differential Revision: https://reviews.llvm.org/D39502
llvm-svn: 317860
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
llvm-svn: 317839
The 'decl' role is more canonical than the 'ref'. This helps us establish the
'specialization-of' relation just by looking at decls or defs.
rdar://31884960
llvm-svn: 317832
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
llvm-svn: 317820
Summary:
This is an alternative to JSONCompilationDatabase for simple projects that
don't use a build system such as CMake.
(You can also drop one in ~, to make your tools use e.g. C++11 by default)
There's no facility for varying flags per-source-file or per-machine.
Possibly this could be accommodated backwards-compatibly using cpp, but even if
not the simplicity seems worthwhile for the cases that are addressed.
Tested with clangd, works great! (requires clangd restart)
Reviewers: klimek
Subscribers: ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D39799
llvm-svn: 317777
I think we need to use different builtins for the FMA4 instructions since those instructions zero the upper bits and FMA3 instructions pass the bits through.
So this moves the existing builtins to be the FMA3 versions. New versions will be added for FMA4.
llvm-svn: 317766
There are some limitations with emitting regions in macro expansions
because we don't gather file IDs within the expansions. Fix the check
that prevents us from emitting deferred regions in expansions to make an
exception for headers, which is something we can handle.
rdar://35373009
llvm-svn: 317760
The area immediately after a terminated region in the function top-level
should have the same count as the label it precedes.
This solves another problem with wrapped segments. Consider:
1| a:
2| return 0;
3| b:
4| return 1;
Without a gap area starting after the first return, the wrapped segment
from line 2 would make it look like line 3 is executed, when it's not.
rdar://35373009
llvm-svn: 317759
The area immediately after the closing right-paren of an if condition
should have a count equal to the 'then' block's count. Use a gap region
to set this count, so that region highlighting for the 'then' block
remains precise.
This solves a problem we have with wrapped segments. Consider:
1| if (false)
2| foo();
Without a gap area starting after the condition, the wrapped segment
from line 1 would make it look like line 2 is executed, when it's not.
rdar://35373009
llvm-svn: 317758
Block literals can have a type with attributes in its signature, e.g.
ns_returns_retained. The code that inspected the type loc of the block when
declaring its parameters didn't account for this fact, and only looked through
paren type loc. This commit ensures that getAsAdjusted is used instead of
IgnoreParens to find the block's FunctionProtoTypeLoc. This ensures that
block parameters are declared correctly in the block and avoids the
'undeclared identifier' error.
rdar://35416160
llvm-svn: 317736
Objective-C NSString has a class method stringWithUTF8String that creates a new
NSString from a C string. Objective-C box expression @(...) can be used to
create an NSString instead of invoking the stringWithUTF8String method directly
(The compiler lowers it down to the invocation though). This commit ensures that
the type of @(string-value) gets the same nullability attributes as the return
type of stringWithUTF8String to ensure that the diagnostics are consistent
between the two.
rdar://33847186
Differential Revision: https://reviews.llvm.org/D39762
llvm-svn: 317727
Do not crash when trying to compute x && y or x || y where x and y are
of a vector type.
For now we do not seem to properly model operations with vectors. In particular,
operations && and || on a pair of vectors are not short-circuit, unlike regular
logical operators, so even our CFG is incorrect.
Avoid the crash, add respective FIXME tests for later.
Differential Revision: https://reviews.llvm.org/D39682
rdar://problem/34317663
llvm-svn: 317700
Summary:
The OccurrencesFinder is only used in RenameOccurrences to find symbol
occurrences, there is no need to inherit RefactoringRule.
Replace it with a single utility function to avoid code misleading.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D39796
llvm-svn: 317696
Summary:
Adjusted PrintingPolicy inside code completion to avoid printing some
redundant name qualifiers.
Before this change, typedefs that were written unqualified in source
code were printed with qualifiers in completion. For example, in the
following code
struct foo {
typedef int type;
type method();
};
completion item for `method` had return type of `foo::type`, even
though the original code used `type` without qualifiers.
After this change, the completion item has return type `type`, as
originally written in the source code.
Note that this change does not suppress qualifiers written by the
user. For example, in the following code
typedef int type;
struct foo {
typedef int type;
::type method(foo::type);
};
completion item for `method` has return type of `::type` and
parameter type of `foo::type`, as originally written in the source
code.
Reviewers: arphaman, bkramer, klimek
Reviewed By: arphaman
Subscribers: mgorny, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D38538
llvm-svn: 317677
Summary:
For code reuse in SemaCodeComplete.
Note that the tests for QualTypeNames are still in Tooling as they use
Tooling's common testing code.
Reviewers: rsmith, saugustine, rnk, klimek, bkramer
Reviewed By: rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39224
llvm-svn: 317676
Summary:
This just seems to have been an oversight. We already supported the f64
atomic add with an explicit scope (e.g. "cta"), but not the scopeless
version.
Reviewers: tra
Subscribers: jholewinski, sanjoy, cfe-commits, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39638
llvm-svn: 317623
Note: This change has a cyclical dependency on D39485. Both these changes must be submitted at the same time to avoid a build breakage.
Reviewers: vlad.tsyrklevich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39486
llvm-svn: 317616
This patch renames some of the flag names of the clang/libomptarget map interface. The old names are slightly misleading, whereas the new ones describe in a better way what each flag is about.
Only the macros within the enumeration are renamed, there is no change in functionality therefore there are no updated regression tests.
Differential Revision: https://reviews.llvm.org/D39745
llvm-svn: 317598
Do not crash when trying to define and call a non-standard
strcpy(unsigned char *, unsigned char *) during analysis.
At the same time, do not try to actually evaluate the call.
Differential Revision: https://reviews.llvm.org/D39422
llvm-svn: 317565
The analyzer's BodyFarm models dispatch_once() by comparing the passed-in
predicate against a known 'done' value. If the predicate does not have that
value, the model updates the predicate to have that value and executes the
passed in block.
Unfortunately, the current model uses the wrong 'done' value: 1 instead of ~0.
This interferes with libdispatch's static inline function _dispatch_once(),
which enables a fast path if the block has already been executed. That function
uses __builtin_assume() to tell the compiler that the done flag is set to ~0 on
exit. When r302880 added modeling of __builtin_assume(), this caused the
analyzer to assume 1 == ~0. This in turn caused the analyzer to never explore any code after a call to dispatch_once().
This patch regains the missing coverage by updating BodyFarm to use the correct
'done' value.
rdar://problem/34413048
Differential Revision: https://reviews.llvm.org/D39691
llvm-svn: 317516
Summary:
This change allows binutils to be used for linking with MSVC. Currently, when
using an MSVC target and `-fuse-ld=bfd`, the driver produces an invalid linker
invocation.
Reviewers: rnk, compnerd
Reviewed By: compnerd
Subscribers: smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D39509
llvm-svn: 317511