This reverts commit r347413: older versions of ld.gold that are used
by Android don't support --push/pop-state which broke sanitizer bots.
llvm-svn: 347430
For the NVPTX target default locations should be emitted as constants +
additional info must be emitted in the reserved_2 field of the ident_t
structure. The 1st bit controls the execution mode and the 2nd bit
controls use of the lightweight runtime. The combination of the bits for
Non-SPMD mode + lightweight runtime represents special undefined mode,
used outside of the target regions for orphaned directives or functions.
Should allow and additional optimization inside of the target regions.
llvm-svn: 347425
Sanitizer runtime link deps handling passes --no-as-needed because of
PR15823, but it never undoes it and this flag may affect other libraries
that come later on the link line. To avoid this, wrap Sanitizer link
deps in --push/pop-state.
Differential Revision: https://reviews.llvm.org/D54805
llvm-svn: 347413
Loop-control variables with the default data-sharing attributes should
not be captured in the OpenMP region as they are private by default.
Also, default attributes should be emitted for such variables in the
inner OpenMP regions for the correct data sharing during codegen.
llvm-svn: 347409
forms of random access iterator
In OpenMP 4.5, only 4 relational operators are supported: <, <=, >,
and >=. This work is to enable support for relational operator
!= (not-equal) as one of the canonical forms.
Patch by Anh Tuyen Tran
Differential Revision: https://reviews.llvm.org/D54441
llvm-svn: 347405
Summary:
Similar to auto-completion for ObjC methods, inherited properties
should be penalized / direct class and category properties should
be prioritized.
Note that currently, the penalty for using a result from a base class
(CCD_InBaseClass) is equal to the penalty for using a method as a
property (CCD_MethodAsProperty).
Reviewers: jkorous, sammccall, akyrtzi, arphaman, benlangmuir
Reviewed By: sammccall, akyrtzi
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53900
llvm-svn: 347352
This patch adjusts a test not to depend on deprecated FileCheck
behavior that permits overlapping matches within a block of CHECK-DAG
directives. Thus, this patch also removes uses of FileCheck's
-allow-deprecated-dag-overlap command-line option.
There were two issues in this test:
1. There were sets of patterns for store instructions in which a
pattern X could match a superset of a pattern Y. While X appeared
before Y, Y's intended match appeared before X's intended match. The
result was that X matched Y's intended match. Under the old
overlapping behavior, Y also matched Y's intended match. Under the
new non-overlapping behavior, Y had nothing left to match. This patch
fixes this by gathering these sets in one place and putting the most
specific patterns (Y) before the more general patterns (X).
2. The CHECK-DAG patterns involving the variables CBPADDR3 and
CBPADDR4 were the same, but there was only one match in the text, so
CBPADDR4 patterns had nothing to match under the new non-overlapping
behavior. Moreover, a preceding related series of directives had
variables (SADDR0, BPADDR0, etc.) numbered only 0 through 4, but this
series had variables numbered 0 through 5. Assuming CBPADDR4's
directives were not intended, this patch removes them.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D54765
llvm-svn: 347351
This patch adjusts a test not to depend on deprecated FileCheck
behavior that permits overlapping matches within a block of CHECK-DAG
directives. Thus, this patch also removes uses of FileCheck's
-allow-deprecated-dag-overlap command-line option.
Specifically, the FileCheck variables DBG_LOC_START, DBG_LOC_END, and
DBG_LOC_CANCEL were all set to the same value. As a result, three
TERM_DEBUG-DAG patterns, one for each variable, all matched the same
text under the old overlapping behavior. Under the new
non-overlapping behavior, that's not permitted. This patch's solution
is to replace these variables with one variable and replace these
patterns with one pattern.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D54764
llvm-svn: 347350
Summary:
clang has `-Wextra-semi` (D43162), which is not dictated by the currently selected standard.
While that is great, there is at least one more source of need-less semis - 'null statements'.
Sometimes, they are needed:
```
for(int x = 0; continueToDoWork(x); x++)
; // Ugly code, but the semi is needed here.
```
But sometimes they are just there for no reason:
```
switch(X) {
case 0:
return -2345;
case 5:
return 0;
default:
return 42;
}; // <- oops
;;;;;;;;;;; <- OOOOPS, still not diagnosed. Clearly this is junk.
```
Additionally:
```
if(; // <- empty init-statement
true)
;
switch (; // empty init-statement
x) {
...
}
for (; // <- empty init-statement
int y : S())
;
}
As usual, things may or may not go sideways in the presence of macros.
While evaluating this diag on my codebase of interest, it was unsurprisingly
discovered that Google Test macros are *very* prone to this.
And it seems many issues are deep within the GTest itself, not
in the snippets passed from the codebase that uses GTest.
So after some thought, i decided not do issue a diagnostic if the semi
is within *any* macro, be it either from the normal header, or system header.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=39111 | PR39111 ]]
Reviewers: rsmith, aaron.ballman, efriedma
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52695
llvm-svn: 347339
Summary:
A __builtin_constant_p may end up with a constant after inlining. Use
the is.constant intrinsic if it's a variable that's in a context where
it may resolve to a constant, e.g., an argument to a function after
inlining.
Reviewers: rsmith, shafik
Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight
Differential Revision: https://reviews.llvm.org/D54355
llvm-svn: 347294
Because SCS relies on system-provided runtime support, we can use it
together with any other sanitizer simply by linking the runtime for
the other sanitizer.
Differential Revision: https://reviews.llvm.org/D54735
llvm-svn: 347282
popRegions used to assume that the start location of a region can't be
nested deeper than the end location, which is not always true.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53244
llvm-svn: 347262
If PerformConstructorInitialization of a direct initializer list constructor is
called while instantiating a template, it has brace locations in its BraceLoc
arguments but not in the Kind argument.
This reverts the hunk https://reviews.llvm.org/D41921#inline-468844.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53231
llvm-svn: 347261
Summary:
As reported by @regehr (thanks!) on twitter (https://twitter.com/johnregehr/status/1057681496255815686),
we (me) has completely forgot about the binary assignment operator.
In AST, it isn't represented as separate `ImplicitCastExpr`'s,
but as a single `CompoundAssignOperator`, that does all the casts internally.
Which means, out of these two, only the first one is diagnosed:
```
auto foo() {
unsigned char c = 255;
c = c + 1;
return c;
}
auto bar() {
unsigned char c = 255;
c += 1;
return c;
}
```
https://godbolt.org/z/JNyVc4
This patch does handle the `CompoundAssignOperator`:
```
int main() {
unsigned char c = 255;
c += 1;
return c;
}
```
```
$ ./bin/clang -g -fsanitize=integer /tmp/test.c && ./a.out
/tmp/test.c:3:5: runtime error: implicit conversion from type 'int' of value 256 (32-bit, signed) to type 'unsigned char' changed the value to 0 (8-bit, unsigned)
#0 0x2392b8 in main /tmp/test.c:3:5
#1 0x7fec4a612b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
#2 0x214029 in _start (/build/llvm-build-GCC-release/a.out+0x214029)
```
However, the pre/post increment/decrement is still not handled.
Reviewers: rsmith, regehr, vsk, rjmccall, #sanitizers
Reviewed By: rjmccall
Subscribers: mclow.lists, cfe-commits, regehr
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D53949
llvm-svn: 347258
Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.
When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).
This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.
The high level changes introduced in this patch are:
1. Removal of functionality - The lit test suite no longer respects
LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
more support for gcc, but nobody was using this anyway (note: The
functionality is still there for the dotest suite, just not the lit test
suite). There is no longer a single substitution %cxx and %cc which maps
to <arbitrary-compiler>, you now explicitly specify the compiler with a
substitution like %clang or %clangxx or %clang_cl. We can revisit this
in the future when someone needs gcc.
2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
more friendly. If this is not specified, all tools are expected to be
the just-built tools. If it is specified, the tools which are not
themselves being tested but are being used to construct and run checks
(e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
directory first, then the build output directory.
3. Changes to core llvm lit files. The use_lld() and use_clang()
functions were introduced long ago in anticipation of using them in
lldb, but since they were never actually used anywhere but their
respective problems, there were some issues to be resolved regarding
generality and ability to use them outside their project.
4. Changes to .test files - These are all just replacing things like
clang-cl with %clang_cl and %cxx with %clangxx, etc.
5. Changes to lit.cfg.py - Previously we would load up some system
environment variables and then add some new things to them. Then do a
bunch of work building out our own substitutions. First, we delete the
system environment variable code, making the environment hermetic. Then,
we refactor the substitution logic into two separate helper functions,
one which sets up substitutions for the tools we want to test (which
must come from the build output directory), and another which sets up
substitutions for support tools (like compilers, etc).
6. New substitutions for MSVC -- Previously we relied on location of
MSVC by bringing in the entire parent's PATH and letting
subprocess.Popen just run the command line. Now we set up real
substitutions that should have the same effect. We use PATH to find
them, and then look for INCLUDE and LIB to construct a substitution
command line with appropriate /I and /LIBPATH: arguments. The nice thing
about this is that it opens the door to having separate %msvc-cl32 and
%msvc-cl64 substitutions, rather than only requiring the user to run
vcvars first. Because we can deduce the path to 32-bit libraries from
64-bit library directories, and vice versa. Without these substitutions
this would have been impossible.
Differential Revision: https://reviews.llvm.org/D54567
llvm-svn: 347216
Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This is fixed by storing all reported fields
to the GDM.
Differential Revision: https://reviews.llvm.org/D51531
llvm-svn: 347153
Summary:
the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows.
So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: cfe-commits, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D54600
llvm-svn: 347144
If lambda is used inside of the OpenMP region and captures `this`, we
should recapture it in the OpenMP region also. But we should do this
only if the OpenMP region is used in the context of the same class, just
like the lambda.
llvm-svn: 347096
reductions.
Fixed previously committed code for the reduction support in
teams/parallel constructs taking into account new design of the NVPTX
support in the compiler. Teams reduction are not fully functional yet,
it is going to be fixed in the following patches.
llvm-svn: 347081
Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.
This removes the LLVM cl::opt and replaces it with a metadata flag.
After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags
Reviewers: zturner, hans, thakis, takuto.ikuta
Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54370
llvm-svn: 347072
Added references to the addr spaces deduction and enabled
CL2.0 features (program scope variables and storage class
qualifiers) to work in C++ mode too.
Fixed several address space conversion issues in CodeGen
for references.
Differential Revision: https://reviews.llvm.org/D53764
llvm-svn: 347059
There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to
choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example,
typedef float __v4sf __attribute__((__vector_size__(16)));
void f(vector float);
void f(vector signed int);
int main {
__v4sf a;
f(a);
}
Here, we'd like to choose f(vector float) but not report an ambiguous call error.
Differential revision: https://reviews.llvm.org/D53417
llvm-svn: 347019
It fixes the case when Objective-C framework is added as a subframework
through a symlink. When parent framework infers a module map and fails
to detect a symlink, it would add a subframework as a submodule. And
when we parse module map for the subframework, we would encounter an
error like
> error: umbrella for module 'WithSubframework.Foo' already covers this directory
By implementing `getRealPath` "an egregious but useful hack" in
`ModuleMap::inferFrameworkModule` works as expected.
LLVM commit is r347009.
rdar://problem/45821279
Reviewers: bruno, benlangmuir, erik.pilkington
Reviewed By: bruno
Subscribers: hiraditya, dexonsmith, JDevlieghere, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54245
llvm-svn: 347012
Extend the alpha.core.Conversion checker to handle implicit converions
where a too large integer value is converted to a floating point type. Each
floating point type has a range where it can exactly represent all integers; we
emit a warning when the integer value is above this range. Although it is
possible to exactly represent some integers which are outside of this range
(those that are divisible by a large enough power of 2); we still report cast
involving those, because their usage may lead to bugs. (For example, if 1<<24
is stored in a float variable x, then x==x+1 holds.)
Patch by: Donát Nagy!
Differential Revision: https://reviews.llvm.org/D52730
llvm-svn: 347006
Summary:
We discussed this at the Nov 12th CG meeting, and decided to use the
unsigned semantics for the wake count.
Corresponding spec change:
https://github.com/WebAssembly/threads/pull/110
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D54572
llvm-svn: 347005
Previously these would be transformed into annotation tokens and the
preprocessor would then assume they were real tokens with source
locations and assert/UB.
Other pragmas that produce annotation tokens aren't a problem because
they aren't handled if the parser isn't hooked up - ParsePragma.cpp
registers those handlers & isn't run for pure preprocessing. So they're
treated as unknown pragmas & printed verbatim by the preprocessor.
Perhaps these pragmas should be treated the same way? But they got mixed
in with other __debug pragmas that do need to be handled during
preprocessing.
The third __debug pragma that produces an annotation token is 'captured'
- which had its own fix for this issue - by not inserting the annotation
token in the first place if it detected that it was in preprocessing
mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more
general one in Frontend/PrintPreprocessedOutput.cpp.
llvm-svn: 346928
Summary: The name of the synthesized constants for constant initialization was using mangling for statics, which isn't generally correct and (in a yet-uncommitted patch) causes the mangler to assert out because the static ends up trying to mangle function parameters and this makes no sense. Instead, mangle to `"__const." + FunctionName + "." + DeclName`.
Reviewers: rjmccall
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D54055
llvm-svn: 346915
Summary:
If you're using the Microsoft ABI, chances are that you want PDBs and
codeview debug info. Currently, everyone has to remember to specific
-gcodeview by default, when it would be nice if the standard -g option
did the right thing by default.
Also, do some related cleanup of -cc1 options. When targetting the MS
C++ ABI, we probably shouldn't pass -debugger-tuning=gdb. We were also
passing -gcodeview twice, which is silly.
Reviewers: smeenai, zturner
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54499
llvm-svn: 346907
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
Summary:
GCC already catches these situations so we should handle it too.
GCC warns in C++ mode only (does anybody know why?). I think it is useful in C mode too.
Reviewers: rsmith, erichkeane, aaron.ballman, efriedma, xbolva00
Reviewed By: xbolva00
Subscribers: efriedma, craig.topper, scanon, cfe-commits
Differential Revision: https://reviews.llvm.org/D52835
llvm-svn: 346865
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, can be
written to the relocatable object (.o) file but ignored by the
linker or they can be written to a separate DWARF object (.dwo)
file that need not be accessed by the linker."
The first part describes a single file split DWARF feature and there
is no way to trigger this behavior atm.
Fortunately, no many changes are required to keep *.dwo sections
in a .o, the patch does that.
Differential revision: https://reviews.llvm.org/D52296
llvm-svn: 346837
Include search paths can be relative paths. The loadSubdirectoryModuleMaps function
should account for that and respect the -working-directory parameter given to Clang.
rdar://46045849
Differential Revision: https://reviews.llvm.org/D54503
llvm-svn: 346822
This avoids spurious warnings, but could use
a lot of work. For example the number of vector
elements is not verified, and the passed
value type is not checked.
Fixes bug 39486
llvm-svn: 346806
ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded somewhere in PREFIX.
Differential Revision: https://reviews.llvm.org/D53770
llvm-svn: 346802
Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked executable bytes), but gold's 32 bit
gdb-index support has a bug (
https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
switch to this unconditionally. (& even if it weren't for that bug, one
might argue that some users would want to optimize in one direction or
the other - prioritizing object size or linked executable size)
Differential Revision: https://reviews.llvm.org/D54243
llvm-svn: 346789
As suggested by Richard Smith, and initially put up for review here:
https://reviews.llvm.org/D53341, this patch removes a hack that was used
to ensure that proper target-feature lists were used when emitting
cpu-dispatch (and eventually, target-clones) implementations. As a part
of this, the GlobalDecl object is proliferated to a bunch more
locations.
Originally, this was put up for review (see above) to get acceptance on
the approach, though discussion with Richard in San Diego showed he
approved of the approach taken here. Thus, I believe this is acceptable
for Review-After-commit
Differential Revision: https://reviews.llvm.org/D53341
Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5
llvm-svn: 346757
Summary: /Zc:dllexportInlines with /fallback may cause unexpected linker error. It is better to disallow compile rather than warn for this combination.
Reviewers: hans, thakis
Reviewed By: hans
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54426
llvm-svn: 346733
Apparently my invocation of clang-format in VIM didn't get this right,
but the patch-version DID. This patch just runs CF on this file.
Change-Id: Ied462a2d921cbb813fa427740d3ef6e97959b56d
llvm-svn: 346696
As approved for the Working Paper in San Diego, support annotating
inline namespaces with 'inline'.
Change-Id: I51a654e11ffb475bf27cccb2458768151619e384
llvm-svn: 346677
Summary:
When they read compiler args from compile_commands.json.
This change allows to run clang-based tools, like clang-tidy or clangd,
built from head using the compile_commands.json file produced for XCode
toolchains.
On MacOS clang can find the C++ standard library relative to the
compiler installation dir.
The logic to do this was based on resource dir as an approximation of
where the compiler is installed. This broke the tools that read
'compile_commands.json' and don't ship with the compiler, as they
typically change resource dir.
To workaround this, we now use compiler install dir detected by the driver
to better mimic the behavior of the original compiler when replaying the
compilations using other tools.
Reviewers: sammccall, arphaman, EricWF
Reviewed By: sammccall
Subscribers: ioeric, christof, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54310
llvm-svn: 346652
Summary:
These options are taking regex separated by colons to filter files.
- if both are empty then all files are instrumented
- if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented
- if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented
- if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented
- this patch is a follow-up of https://reviews.llvm.org/D52033
Reviewers: marco-c, vsk
Reviewed By: marco-c, vsk
Subscribers: cfe-commits, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D52034
llvm-svn: 346642
Summary: This adds support for Swift platform availability attributes. It's largely a port of the changes made to https://github.com/apple/swift-clang/ for Swift availability attributes. Specifically, 84b5a21c31 and e5b87f265a . The implementation of attribute_availability_swift is a little different and additional tests in test/Index/availability.c were added.
Reviewers: manmanren, friss, doug.gregor, arphaman, jfb, erik.pilkington, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: aaron.ballman, ColinKinloch, jrmuizel, cfe-commits
Differential Revision: https://reviews.llvm.org/D50318
llvm-svn: 346633
Summary:
Class with no user-defined destructor that has an inherited member that has a
non-trivial destructor and a non-default constructor will attempt to emit a
destructor despite being marked as __attribute((no_destroy)) in which case it
would trigger an assertion due to an incorrect assumption.
In addition this adds missing test coverage for IR generation for no_destroy.
(Note that here use of no_destroy is synonymous with its global flag
counterpart `-fno-c++-static-destructors` being enabled)
Differential Revision: https://reviews.llvm.org/D54344
llvm-svn: 346628
Fix places where the return type of a FunctionDecl was being used in
place of the function type
FunctionDecl::Create() takes as its T parameter the type of function
that should be created, not the return type. Passing in the return type
looks to have been copypasta'd around a bit, but the number of correct
usages outweighs the incorrect ones so I've opted for keeping what T is
the same and fixing up the call sites instead.
This fixes a crash in Clang when attempting to compile the following
snippet of code with -fblocks -fsanitize=function -x objective-c++ (my
original repro case):
void g(void(^)());
void f()
{
__block int a = 0;
g(^(){ a++; });
}
as well as the following which only requires -fsanitize=function -x c++:
void f(char * buf)
{
__builtin_os_log_format(buf, "");
}
Patch by: Ben (bobsayshilol)
Differential revision: https://reviews.llvm.org/D53263
llvm-svn: 346601
If the statements between target|teams|distribute directives does not
require execution in master thread, like constant expressions, null
statements, simple declarations, etc., such construct can be xecuted in
SPMD mode.
llvm-svn: 346551
r344915 added a call to ApplyDebugLocation to the sanitizer check
function emitter. Some of the sanitizers are emitted in the function
epilogue though and the LexicalScopeStack is emptied out before. By
detecting this situation and early-exiting from ApplyDebugLocation the
fallback location is used, which is equivalent to the return location.
rdar://problem/45859802
........
Causes EXPENSIVE_CHECKS build bot failures: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win
llvm-svn: 346549
This matches a similar behavior with GCC accepting [[gnu::__attr__]] as a alias for [[gnu::attr]] in that clang attributes can now be spelled with two leading and trailing underscores.
I had always intended for this to work, but missed the critical bit. We already had an existing test in test/Preprocessor/has_attribute.cpp for [[clang::__fallthrough__]] but using that spelling would still give an "unknown attribute" diagnostic.
llvm-svn: 346547
The artificial variable describing the array size is supposed to be
called "__vla_expr", but this was implemented by retrieving the name
of the associated alloca, which isn't a reliable source for the name,
since nonassert compilers may drop names from LLVM IR.
rdar://problem/45924808
llvm-svn: 346542
Currently, we only accept clang as the scoped attribute identifier for double square bracket attributes provided by Clang, but this has the potential to conflict with user-defined macros. To help alleviate these concerns, this introduces the _Clang scoped attribute identifier as an alias for clang. It also introduces a warning with a fixit on the off chance someone attempts to use __clang__ as the scoped attribute (which is a predefined compiler identification macro).
llvm-svn: 346521
target|teams|distribute variables.
If the total size of the variables, declared in target|teams|distribute
regions, is less than the maximal size of shared memory available, the
buffer is allocated in the shared memory.
llvm-svn: 346507
The second parameter of vec_sr function is representing shift bits and it should be modulo the number of bits in the element like what vec_sl does now.
This is actually required by the ABI:
Each element of the result vector is the result of logically right shifting the corresponding
element of ARG1 by the number of bits specified by the value of the corresponding
element of ARG2, modulo the number of bits in the element. The bits that are shifted out
are replaced by zeros.
Differential Revision: https://reviews.llvm.org/D54087
llvm-svn: 346471
Summary:
Compound literals, enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.
Reviewers: rsmith, shafik
Reviewed By: rsmith
Subscribers: cfe-commits, jyknight, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D53921
llvm-svn: 346455
r344915 added a call to ApplyDebugLocation to the sanitizer check
function emitter. Some of the sanitizers are emitted in the function
epilogue though and the LexicalScopeStack is emptied out before. By
detecting this situation and early-exiting from ApplyDebugLocation the
fallback location is used, which is equivalent to the return location.
rdar://problem/45859802
llvm-svn: 346454
The current version only emits the below error for a module (attempted to be loaded) from the `prebuilt-module-path`:
```
error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch]
```
With this change, if the prebuilt module is used, we allow the proper diagnostic behind the configuration mismatch to be shown.
```
error: POSIX thread support was disabled in PCH file but is currently enabled
error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch]
```
(A few lines later an error is emitted anyways, so there is no reason not to complain for configuration mismatches if a config mismatch is found and kills the build.)
Reviewed By: dblaikie
Tags: #clang
Differential Revision: https://reviews.llvm.org/D53334
llvm-svn: 346439
Coerced load/stores through memory do not take into account potential
address space differences when it creates its bitcasts.
Patch by David Salinas.
Differential Revision: https://reviews.llvm.org/D53780
llvm-svn: 346413
The base pointer for the lambda mapping must point to the lambda capture
placement and pointer must point to the captured variable itself. Patch
fixes this problem.
llvm-svn: 346408
The clang-cl driver disables access to command line options outside of the
"Core" and "CLOption" sets of command line arguments. This filtering makes it
impossible to pass arguments that are interpreted by the clang driver and not
by either 'cc1' (the frontend) or one of the other tools invoked by the driver.
An example driver-level flag is the '-fno-slp-vectorize' flag, which is
processed by the driver in Clang::ConstructJob and used to set the cc1 flag
"-vectorize-slp". There is no negative cc1 flag or -mllvm flag, so it is not
currently possible to disable the SLP vectorizer from the clang-cl driver.
This change introduces the "/clang:" argument that is available when the
driver mode is set to CL compatibility. This option works similarly to the
"-Xclang" option, except that the option values are processed by the clang
driver rather than by 'cc1'. An example usage is:
clang-cl /clang:-fno-slp-vectorize /O2 test.c
Another example shows how "/clang:" can be used to pass a flag where there is
a conflict between a clang-cl compat option and an overlapping clang driver
option:
clang-cl /MD /clang:-MD /clang:-MF /clang:test_dep_file.dep test.c
In the previous example, the unprefixed /MD selects the DLL version of the msvc
CRT, while the prefixed -MD flag and the -MF flags are used to create a make
dependency file for included headers.
One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.
Patch by Neeraj K. Singh!
Differential revision: https://reviews.llvm.org/D53457
llvm-svn: 346393
Fixed lookup for the target regions in unused virtual functions + fixed
processing of the global variables not marked as declare target but
emitted during debug info emission.
llvm-svn: 346343
This patch breaks Index/opencl-types.cl LIT test:
Script:
--
: 'RUN: at line 1'; stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl
--
Command Output (stderr):
--
llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed
llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm-svn: 346338
Summary:
I wonder if there are some extension which need to be disabled to get
overloadable candidate available.
Reviewers: asavonic, Anastasia
Reviewed By: Anastasia
Subscribers: yaxunl, sidorovd, cfe-commits
Differential Revision: https://reviews.llvm.org/D54152
llvm-svn: 346311
This patch fixes a minimum divider for offset in intrinsics
msa_[st/ld]_[b/h/w/d], when value is known in compile time.
Differential revision: https://reviews.llvm.org/D54038
llvm-svn: 346302
Summary:
Removes references to initialized variable from the following completions:
int x = ^;
Handles only the trivial cases where the variable name is completed
immediately at the start of initializer or assignment, more complicated
cases aren't covered, e.g. these completions still contain 'x':
// More complicated expressions.
int x = foo(^);
int x = 10 + ^;
// Other kinds of initialization.
int x{^};
int x(^);
// Constructor initializers.
struct Foo {
Foo() : x(^) {}
int x;
};
We should address those in the future, but they are outside of the scope of
this initial change.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D54156
llvm-svn: 346301
Summary:
Some CPUID leafs depend on the value of ECX as well as EAX, but we left
it uninitialized.
Originally reported as https://crbug.com/901547
Reviewers: craig.topper, hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54171
llvm-svn: 346265
A mask type is a 1 to 8-byte string that follows the "mask." annotation
in the format string. This enables obfuscating data in the event the
provided privacy level isn't enabled.
rdar://problem/36756282
llvm-svn: 346211
This is a stricter privacy annotation than "private", which will be used
for data that shouldn’t be logged to disk. For backward compatibility,
the "private" bit is set too.
rdar://problem/36755912
llvm-svn: 346210
This is fifth in a series of patches to move intrinsic definitions out of intrin.h.
Note: This was reviewed and approved in D54065 but somehow that diff was messed
up. Committing this again with the proper diff.
llvm-svn: 346205
The test hits stack overflow trying to instantiate recursive templates.
It is observed with ASAN and not with a regular build because ASAN
increases stack frame size.
rdar://problem/45009892
Reviewers: george.karpenkov, lebedev.ri
Reviewed By: george.karpenkov
Subscribers: dexonsmith, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D54132
llvm-svn: 346200
Summary: This is fifth in a series of patches to move intrinsic definitions out of intrin.h.
Reviewers: rnk, efriedma, mstorsjo, TomTan
Reviewed By: efriedma
Subscribers: javed.absar, kristof.beyls, chrib, jfb, kristina, cfe-commits
Differential Revision: https://reviews.llvm.org/D54065
llvm-svn: 346191
Summary: This is third in a series of patches to move intrinsic definitions out of intrin.h.
Reviewers: rnk, efriedma, mstorsjo, TomTan
Reviewed By: efriedma
Subscribers: javed.absar, kristof.beyls, chrib, jfb, kristina, cfe-commits
Differential Revision: https://reviews.llvm.org/D54062
llvm-svn: 346189
Summary:
Previously the TemplateSpecialization instance for 'template_alias', in the example below, returned the type info of the canonical type (int). This ignored the type alias if the template type happen to be aliased.
Before this patch, the assert would trigger with an alignment of 4:
```
typedef int __attribute__(( aligned( 16 ) )) aligned_int;
template < typename >
using template_alias = aligned_int;
static_assert( alignof( template_alias<void>) == 16, "" );
```
This patch checks if the TemplateSpecialization type has an alias, and if so will return the type information for the aliased type, else the canonical type's info is returned (original behavior). I believe that this is the desired behavior.
Reviewers: aaron.ballman, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54048
llvm-svn: 346146
This reverts commit r345963. We have a path forward now.
Original commit message:
The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.
This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.
llvm-svn: 346130
Test builtins-mips-msa-error.c wasn't reporting errors.
This patch fixes the test, so further test cases can be added.
Differential Revision: https://reviews.llvm.org/D53984
llvm-svn: 346124
-static relies on lld's behavior, but -Bstatic/dynamic is supported
across all linkers.
Differential Revision: https://reviews.llvm.org/D54082
llvm-svn: 346107
This patch adds a couple new functions to acquire the macro's name, and also
expands it, although it doesn't expand the arguments, as seen from the test files
Differential Revision: https://reviews.llvm.org/D52794
llvm-svn: 346095
This makes the tests stricter by not only matching the runtime file
name, but the entire path into the resource directory.
Differential Revision: https://reviews.llvm.org/D54064
llvm-svn: 346088
Summary:
The test case added in this diff would incorrectly warn that control
flow may fall through without returning. Here's a standalone example:
https://godbolt.org/z/dCwXEi
The same program, but using `return` instead of `co_return`, does not
produce a warning: https://godbolt.org/z/mVldqQ
The issue was in how Clang analysis would structure its representation
of the control-flow graph. Specifically, when constructing the CFG,
`CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it
would place object destructors in the same CFG block as a `return` statement,
immediately after it. Doing so would allow the logic in
`lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the
program that used `return`, correctly determining that no "plain edges" preceded
the exit block of the function.
Because a `co_return` statement would not enjoy the same treatment when
it was being built into the control-flow graph, object destructors
would not be placed in the same CFG block as the `co_return`, thus
resulting in a "plain edge" preceding the exit block of the function,
and so the warning logic would be triggered.
Add special casing for `co_return` to Clang analysis, thereby
remedying the mistaken warning.
Test Plan: `check-clang`
Reviewers: GorNishanov, tks2103, rsmith
Reviewed By: GorNishanov
Subscribers: EricWF, lewissbaker, cfe-commits
Differential Revision: https://reviews.llvm.org/D54075
llvm-svn: 346074
This test checks the entire output of a help option, the problem
is that on Windows, the line break occurs in a different place
causing the CHECK to fail because it is not expecting a line break.
llvm-svn: 346070
Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables.
By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables.
On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below.
These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied
* https://chromium-review.googlesource.com/c/chromium/src/+/1212379
* https://chromium-review.googlesource.com/c/v8/v8/+/1186017
Below stats were taken with this patch applied on a05115cd4c
| config | build time | speedup | build dir size |
| with patch, PCH on, debug | 1h10m0s | x1.13 | 35.6GB |
| without patch, PCH on, debug | 1h19m17s | | 49.0GB |
| with patch, PCH off, debug | 1h15m45s | x1.16 | 33.7GB |
| without patch, PCH off, debug | 1h28m10s | | 52.3GB |
| with patch, PCH on, release | 1h13m13s | x1.22 | 26.2GB |
| without patch, PCH on, release | 1h29m57s | | 37.5GB |
| with patch, PCH off, release | 1h23m38s | x1.32 | 23.7GB |
| without patch, PCH off, release | 1h50m50s | | 38.7GB |
This patch reduced obj size and the number of exported symbols largely, that improved link time too.
e.g. link time stats of blink_core.dll become like below
| | cold disk cache | warm disk cache |
| with patch, PCH on, debug | 71s | 30s |
| without patch, PCH on, debug | 111s | 48s |
This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats.
Bug: https://bugs.llvm.org/show_bug.cgi?id=33628
Reviewers: hans, thakis, rnk, javed.absar
Reviewed By: hans
Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman
Differential Revision: https://reviews.llvm.org/D51340
llvm-svn: 346069
This exposes a (known) CodeGen bug: it can't cope with emitting lvalue
expressions that denote non-odr-used but usable-in-constant-expression
variables. See PR39528 for a testcase.
Reverted for now until that issue can be fixed.
llvm-svn: 346065
This avoids introducing unnecessary DT_NEEDED entries when using
C++ driver for linking C code or C++ code that doesn't use C++
standard library.
Differential Revision: https://reviews.llvm.org/D53854
llvm-svn: 346064
Summary: Windows SDK needs these intrinsics to be proper builtins. This is second in a series of patches to move intrinsic defintions out of intrin.h.
Reviewers: rnk, mstorsjo, efriedma, TomTan
Reviewed By: rnk, efriedma
Subscribers: javed.absar, kristof.beyls, chrib, jfb, kristina, cfe-commits
Differential Revision: https://reviews.llvm.org/D54046
llvm-svn: 346044
Handle it in the driver and propagate it to cc1
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52615
llvm-svn: 346001
Coalesced memory access requires use of the new function
`__kmpc_data_sharing_coalesced_push_stack` instead of the
`__kmpc_data_sharing_push_stack`.
llvm-svn: 345991
Interestingly, this many year old (when I last looked I remember 2010ish)
checker was committed without any tests, so I thought I'd implement them, but I
was shocked to see how I barely managed to get it working. The code is severely
outdated, I'm not even sure it has ever been used, so I'd propose to move it
back into alpha, and possibly even remove it.
Differential Revision: https://reviews.llvm.org/D53856
llvm-svn: 345990
I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is to emit warnings if an invalid -analyzer-config option is given from
the command line, and be able to list them all.
In this patch, I found some flags that should've been used as checker options,
or have absolutely no mention of in AnalyzerOptions, or are nonexistent.
- NonLocalizedStringChecker now uses its "AggressiveReport" flag as a checker
option
- lib/StaticAnalyzer/Frontend/ModelInjector.cpp now accesses the "model-path"
option through a getter in AnalyzerOptions
- -analyzer-config path-diagnostics-alternate=false is not a thing, I removed it,
- lib/StaticAnalyzer/Checkers/AllocationDiagnostics.cpp and
lib/StaticAnalyzer/Checkers/AllocationDiagnostics.h are weird, they actually
only contain an option getter. I deleted them, and fixed RetainCountChecker
to get it's "leak-diagnostics-reference-allocation" option as a checker option,
- "region-store-small-struct-limit" has a proper getter now.
Differential Revision: https://reviews.llvm.org/D53276
llvm-svn: 345985
The previously used combination `PTR_AND_OBJ | PRIVATE` could be used for mapping of some data in Fortran. Changed it to `PTR_AND_OBJ | LITERAL`.
llvm-svn: 345982
target/teams/distribute regions.
Target/teams/distribute regions exist for all the time the kernel is
executed. Thus, if the variable is declared in their context and then
escape it, we can allocate global memory statically instead of
allocating it dynamically.
Patch captures all the globalized variables in target/teams/distribute
contexts, merges them into the records, one per each target region.
Those records are then joined into the union, one per compilation unit
(to save the global memory). Those units are organized into
2 x dimensional arrays, where the first dimension is
the number of blocks per SM and the second one is the number of SMs.
Runtime functions manage this global memory space between the executing
teams.
llvm-svn: 345978
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.
This also moves the OSLog and other FormatString helpers from
libclangAnalysis to libclangAST to avoid a circular dependency.
llvm-svn: 345971
This reverts commit r345803 and r345915 (a follow-up fix to r345803).
Reason: r345803 blocks our internal integrate because of the new
warnings showing up in too many places. The fix is actually correct,
we will reland it after figuring out how to integrate properly.
llvm-svn: 345963
Failed assertion is
> Assertion failed: ((ND->isUsed(false) || !isa<VarDecl>(ND) || !E->getLocation().isValid()) && "Should not use decl without marking it used!"), function EmitDeclRefLValue, file llvm-project/clang/lib/CodeGen/CGExpr.cpp, line 2437.
`EmitDeclRefLValue` mentions
> // A DeclRefExpr for a reference initialized by a constant expression can
> // appear without being odr-used. Directly emit the constant initializer.
The fix is to use the similar approach for non-references as for references. It
is achieved by trying to emit a constant before we attempt to load non-odr-used
variable as LValue.
rdar://problem/40650504
Reviewers: ahatanak, rjmccall
Reviewed By: rjmccall
Subscribers: dexonsmith, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53674
llvm-svn: 345903
SARIF allows you to export descriptions about rules that are present in the SARIF log. Expose the help text table generated into Checkers.inc as the rule's "full description" and export all of the rules present in the analysis output. This information is useful for analysis result viewers like CodeSonar.
llvm-svn: 345874
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.
This also moves the OSLog helpers from libclangAnalysis to libclangAST
to avoid a circular dependency.
llvm-svn: 345866
This also reverts a couple of follow-up commits trying to fix the
dependency issues. Latest revision added a cyclic dependency that can't
just be patched up in 5 minutes.
llvm-svn: 345846
Summary:
Instead of providing generic "args" for member and base class
initializers, tries to fetch relevant constructors and show their signatures.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ZaMaZaN4iK, eraman, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53654
llvm-svn: 345844
Multiverson function versions are always used (by the resolver), so ensure that
they are always emitted.
Change-Id: I5d2e0841fddf0d18918b3fb92ae76814add7ee96
llvm-svn: 345839
The member type creation for a cpu-dispatch function was not correctly
including the 'this' parameter, so ensure that the type is properly
determined. Also, disable defer in the cases of emitting the functoins,
as it can end up resulting in the wrong version being emitted.
Change-Id: I0b8fc5e0b0d1ae1a9d98fd54f35f27f6e5d5d083
llvm-svn: 345838
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.
llvm-svn: 345828
When a dispatch function was being emitted that had both a generic and a
pentium configuration listed, we would assert. This is because neither
configuration has any 'features' associated with it so they were both
considered the 'default' version. 'pentium' lacks any features because
we implement it in terms of __builtin_cpu_supports (instead of Intel
proprietary checks), which is unable to decern between the two.
The fix for this is to omit the 'generic' version from the dispatcher if
both are present. This permits existing code to compile, and still will
choose the 'best' version available (since 'pentium' is technically
better than 'generic').
Change-Id: I4b69f3e0344e74cbdbb04497845d5895dd05fda0
llvm-svn: 345826
Bill Wendling