Exactly what it says on the tin! The comments in the code detail this a
little more too.
Differential Revision: https://reviews.llvm.org/D64272
llvm-svn: 368817
Summary: https://reviews.llvm.org/D50923 enabled the IR printing support for the new pass manager, but only for the case when `opt` tool is used as a driver. This patch is to enable the IR printing when `clang` is used as a driver.
Reviewers: fedor.sergeev, philip.pfaffe
Subscribers: cfe-commits, yamauchi, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65975
llvm-svn: 368804
Summary:
Previously __has_builtin(__builtin_*) would return false for
__builtin_*s that we modeled as keywords rather than as functions
(because they take type arguments). With this patch, all builtins
that are called with function-call-like syntax return true from
__has_builtin (covering __builtin_* and also the __is_* and __has_* type
traits and the handful of similar builtins without such a prefix).
Update the documentation on __has_builtin and on type traits to match.
While doing this I noticed the type trait documentation was out of date
and incomplete; that's fixed here too.
Reviewers: aaron.ballman
Subscribers: jfb, kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66100
llvm-svn: 368785
Summary:
The following code snippet taken from D64271#1572188 has an issue: namely,
because `flag`'s value isn't undef or a concrete int, it isn't being tracked.
int flag;
bool coin();
void foo() {
flag = coin();
}
void test() {
int *x = 0;
int local_flag;
flag = 1;
foo();
local_flag = flag;
if (local_flag)
x = new int;
foo();
local_flag = flag;
if (local_flag)
*x = 5;
}
This, in my opinion, makes no sense, other values may be interesting too.
Originally added by rC185608.
Differential Revision: https://reviews.llvm.org/D64287
llvm-svn: 368773
During the evaluation of D62883, I noticed a bunch of totally
meaningless notes with the pattern of "Calling 'A'" -> "Returning value"
-> "Returning from 'A'", which added no value to the report at all.
This patch (not only affecting tracked conditions mind you) prunes
diagnostic messages to functions that return a value not constrained to
be 0, and are also linear.
Differential Revision: https://reviews.llvm.org/D64232
llvm-svn: 368771
They're useful when trying to understand what's going on
inside your LazyCompoundValues.
Differential Revision: https://reviews.llvm.org/D65427
llvm-svn: 368769
When -trim-egraph is unavailable (say, when you're debugging a crash on
a real-world code that takes too long to reduce), it makes sense to view
the untrimmed graph up to the crashing node's predecessor, then dump the ID
(or a pointer) of the node in the attached debugger, and then trim
the dumped graph in order to keep only paths from the root to the node.
The newly added --to flag does exactly that:
$ exploded-graph-rewriter.py ExprEngine.dot --to 0x12229acd0
Multiple nodes can be specified. Stable IDs of nodes can be used
instead of pointers.
Differential Revision: https://reviews.llvm.org/D65345
llvm-svn: 368768
Explorers aren't the right abstraction. For the purposes of displaying svg files
we don't care in which order do we explore the nodes. We may care about this for
other analyses, but we're not there yet.
The function of cutting out chunks of the graph is performed poorly by
the explorers, because querying predecessors/successors on the explored nodes
yields original successors/predecessors even if they aren't being explored.
Introduce a new entity, "trimmers", that do one thing but to it right: cut out
chunks of the graph. Trimmers mutate the graph, so stale edges aren't even
visible to their consumers in the pipeline. Additionally, trimmers are
intrinsically composable: multiple trimmers can be applied to the graph
sequentially.
Refactor the single-path explorer into the single-path trimmer.
Rename the test file for consistency.
Differential Revision: https://reviews.llvm.org/D65344
llvm-svn: 368767
Change the default behavior: the tool no longer dumps the rewritten .dot file
to stdout, but instead it automatically converts it into an .html file
(which essentially wraps an .svg file) and immediately opens it with
the default web browser.
This means that the tool should now be fairly easy to use:
$ exploded-graph-rewriter.py /tmp/ExprEngine.dot
The benefits of wrapping the .svg file into an .html file are:
- It'll open in a web browser, which is the intended behavior.
An .svg file would be open with an image viewer/editor instead.
- It avoids the white background around the otherwise dark svg area
in dark mode.
The feature can be turned off by passing a flag '--rewrite-only'.
The LIT substitution is updated to enforce the old mode because
we don't want web browsers opening on our buildbots.
Differential Revision: https://reviews.llvm.org/D65250
llvm-svn: 368766
Summary:
In the WebAssembly backend, when lowering variadic function calls, non-single
member aggregate type arguments are always passed by pointer.
However, when emitting va_arg code in clang, the arguments are instead read as
if they are passed directly. This results in the pointer being read as the
actual structure.
Fixes https://github.com/emscripten-core/emscripten/issues/9042.
Reviewers: tlively, sbc100, kripken, aheejin, dschuff
Reviewed By: dschuff
Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66168
llvm-svn: 368750
- Create ASTContext::attachCommentsToJustParsedDecls so we don't have to load external comments in Sema when trying to attach existing comments to just parsed Decls.
- Keep comments ordered and cache their decomposed location - faster SourceLoc-based searching.
- Optimize work with redeclarations.
- Keep one comment per redeclaration chain (represented by canonical Decl) instead of comment per redeclaration.
- For redeclaration chains with no comment attached keep just the last declaration in chain that had no comment instead of every comment-less redeclaration.
Differential Revision: https://reviews.llvm.org/D65301
llvm-svn: 368732
This fixes a regression from r365860: As that commit message
states, there are 3 valid states targeted by the combination of
-f(no-)omit-frame-pointer and -m(no-)omit-leaf-frame-pointer.
After r365860 it's impossible to get from state 10 (omit just
leaf frame pointers) to state 11 (omit all frame pointers)
in a single command line without getting a warning.
This change restores that functionality.
Fixes PR42966.
Differential Revision: https://reviews.llvm.org/D66142
llvm-svn: 368728
Clang currently crashes for switch statements inside a template when
the condition is a non-integer field. The crash is due to incorrect
type-dependency of field. Type-dependency of member expressions is
currently set based on the containing class. This patch changes this for
'members of the current instantiation' to set the type dependency based
on the member's type instead.
A few lit tests started to fail once I applied this patch because errors
are now diagnosed earlier (does not wait till instantiation). I've modified
these tests in this patch as well.
Patch fixes PR#40982
Differential Revision: https://reviews.llvm.org/D61027
llvm-svn: 368706
Summary:
Some tests perform deep recursion, which requires a larger pthread stack
size than the relatively low default of 192 KiB for 64-bit processes on
AIX. The `AIXTHREAD_STK` environment variable provides a non-intrusive
way to request a larger pthread stack size for the tests. The required
pthread stack size depends on the build configuration.
A 4 MiB default is generous compared to the 512 KiB of macOS; however,
it is known that some compilers on AIX produce code that uses
comparatively more stack space.
Reviewers: xingxue, daltenty, jasonliu
Reviewed By: daltenty
Subscribers: arphaman, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65688
llvm-svn: 368690
Summary:
As explained in http://lists.llvm.org/pipermail/llvm-dev/2018-March/121924.html,
the LLVM coroutines transforms are not yet able to move the
instructions for UBSan null checking past coroutine suspend boundaries.
For now, disable all UBSan checks when generating code for coroutines
functions.
I also considered an approach where only '-fsanitize=null' would be disabled,
However in practice this led to other LLVM errors when writing object files:
"Cannot represent a difference across sections". For now, disable all
UBSan checks until coroutine transforms are updated to handle them.
Test Plan:
1. check-clang
2. Compile the program in https://gist.github.com/modocache/54a036c3bf9c06882fe85122e105d153
using the '-fsanitize=null' option and confirm it does not crash
during LLVM IR generation.
Reviewers: GorNishanov, vsk, eric_niebler, lewissbaker
Reviewed By: vsk
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D44672
llvm-svn: 368675
Summary:
Adding is_anonymous the ASTDump for CXXRecordDecl. This turned out to be useful when debugging some problems with how LLDB creates ASTs from DWARF.
Differential Revision: https://reviews.llvm.org/D66028
llvm-svn: 368591
The sampler handling logic in SemaInit.cpp would inadvertently treat
parentheses around sampler arguments as an implicit cast, leading to
an unreachable "can't implicitly cast lvalue to rvalue with
this cast kind". Fix by ignoring parentheses once we are in the
sampler initializer case.
Differential Revision: https://reviews.llvm.org/D66080
llvm-svn: 368561
Support -march=tigerlake for x86.
Compare with Icelake Client, It include 4 more new features ,they are
avx512vp2intersect, movdiri, movdir64b, shstk.
Patch by Xiang Zhang (xiangzhangllvm)
Differential Revision: https://reviews.llvm.org/D65840
llvm-svn: 368543
The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:
- There is a performance and code size overhead associated with each
exported function, because each such function must have an associated
jump table entry, which must be emitted even in the common case where the
function is never address-taken anywhere in the program, and must be used
even for direct calls between DSOs, in addition to the PLT overhead.
- There is no good way to take a CFI-valid address of a function written in
assembly or a language not supported by Clang. The reason is that the code
generator would need to insert a jump table in order to form a CFI-valid
address for assembly functions, but there is no way in general for the
code generator to determine the language of the function. This may be
possible with LTO in the intra-DSO case, but in the cross-DSO case the only
information available is the function declaration. One possible solution
is to add a C wrapper for each assembly function, but these wrappers can
present a significant maintenance burden for heavy users of assembly in
addition to adding runtime overhead.
For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.
This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.
Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.
Fixes PR41972.
Differential Revision: https://reviews.llvm.org/D65629
llvm-svn: 368495
Summary:
This patch adds support for the close map modifier in Clang.
This ensures that the new map type is marked and passed to the OpenMP runtime appropriately.
Additional regression tests have been merged from patch D55892 (author @saghir).
Reviewers: ABataev, caomhin, jdoerfert, kkwli0
Reviewed By: ABataev
Subscribers: kkwli0, Hahnfeld, saghir, guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65341
llvm-svn: 368491
This regressed in r368322, and was reported as PR42948 and on the
mailing list. The fix is to ignore the specific error code for this
case. The problem doesn't seem to reproduce on Windows, where a
different error code is used instead.
llvm-svn: 368475
CFStrings should be 8-byte aligned when built for the Swift CF runtime
ABI as the atomic CF info field must be properly aligned. This is a
problem on 32-bit platforms which would give the structure 4-byte
alignment rather than 8-byte alignment.
llvm-svn: 368471
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:
https://developer.arm.com/docs/100986/0000
It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:
(1) trying to generate LLVM IR for the types
(2) trying to generate debug info for the types
(3) trying to mangle the types using the Microsoft C++ ABI
(4) trying to @encode the types in Objective C
(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change. There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.
The intention is that the types will become sizeless types:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html
The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.
Until then, the patch sets the alignments of the types to the values
specified in the link above. It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).
The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other. After this patch, the two pieces of work are
essentially independent.
The patch is based on one by Graham Hunter:
https://reviews.llvm.org/D59245
Differential Revision: https://reviews.llvm.org/D62960
llvm-svn: 368413
Port existing headers which include x86 intrinsics implementation to
PowerPC platform (using Altivec), along with tests. Also, tests about
including these intrinsic headers are combined.
The headers are mainly developed by Steven Munroe, with contributions
from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu.
Reviewed By: Jinsong Ji
Differential Revision: https://reviews.llvm.org/D65630
llvm-svn: 368392
Summary:
A condition could be a multi-line expression where we create the highlight
in separated chunks. PathDiagnosticPopUpPiece is not made for that purpose,
it cannot be added to multiple lines because we have only one ending part
which contains all the notes. So that it cannot have multiple endings and
therefore this patch narrows down the ranges of the highlight to the given
interesting variable of the condition. It prevents HTML-breaking injections.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D65663
llvm-svn: 368382
Summary:
Added support for basic analysis of the linear variables and linear step
expression. Linear loop iteration variables must be excluded from this
analysis, only non-loop iteration variables must be analyzed.
Reviewers: NoQ
Subscribers: guansong, cfe-commits, caomhin, kkwli0
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65461
llvm-svn: 368295
Summary:
The maximum alignment used by ARM arch
is 64bits, not 128.
This could cause overaligned memory
access for 128 bit neon vector that
have unpredictable behaviour.
This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668
Reviewers: ostannard, dmgreen, srhines, danalbert, pirama, peter.smith
Reviewed By: pirama, peter.smith
Subscribers: phosek, thegameg, thakis, llvm-commits, carwil, peter.smith, javed.absar, kristof.beyls, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65000
llvm-svn: 368288
Fixes PR16786
Currently, library paths specified by LIBRARY_PATH are placed after inputs: `inputs LIBRARY_PATH stdlib`
In gcc, the order is: `LIBRARY_PATH inputs stdlib` if not cross compiling.
(On Darwin targets, isCrossCompiling() always returns false.)
This patch changes the behavior to match gcc.
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D65880
llvm-svn: 368245
Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists.
The new fix-it hints for removing the std::move call will now also suggest
removing the braces for the initializer list so that the resulting code will
still be compilable.
This fixes PR42832
llvm-svn: 368237
According to the OpenMP standard, compiler must define _OPENMP macro,
which has value in format yyyymm, where yyyy is the year of the standard
and mm is the month of the standard. For OpenMP 5.0 this value must be
set to 201811.
llvm-svn: 368170
Summary:
Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions
some types explicitly. Generally, all containers and their iterators are
covered. For iterators, we cover both the case that they are defined
as an nested class or as an typedef/using. I have started to test this
implementation against some real standard library implementations, namely
libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5,
libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0,
libstdc++ 8.3.0 and libstdc++ 9.1.0.
The tests are currently here
https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.shhttps://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp
I think due to their dependency on a standard library, they are not a good fit
for clang/test/. Where else could I put them?
Reviewers: gribozavr, xazax.hun
Subscribers: rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64448
llvm-svn: 368147
Summary:
An inline asm call may result in an immediate input value after inlining.
Therefore, don't emit a diagnostic here if the input isn't an immediate.
Reviewers: joerg, eli.friedman, rsmith
Subscribers: asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, s.egerton, krytarowski, mgorny, riccibruno, eraman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60943
llvm-svn: 368104
Globals are instrumented by adding a pointer tag to their symbol values
and emitting metadata into a special section that allows the runtime to tag
their memory when the library is loaded.
Due to order of initialization issues explained in more detail in the comments,
shadow initialization cannot happen during regular global initialization.
Instead, the location of the global section is marked using an ELF note,
and we require libc support for calling a function provided by the HWASAN
runtime when libraries are loaded and unloaded.
Based on ideas discussed with @evgeny777 in D56672.
Differential Revision: https://reviews.llvm.org/D65770
llvm-svn: 368102
Summary:
This change gives Emscripten the ability to use more than one constructor
priorities that runs before ASan. By convention, constructor priorites 0-100
are reserved for use by the system. ASan on Emscripten now uses priority 50,
leaving plenty of room for use by Emscripten before and after ASan.
This change is done in response to:
https://github.com/emscripten-core/emscripten/pull/9076#discussion_r310323723
Reviewers: kripken, tlively, aheejin
Reviewed By: tlively
Subscribers: cfe-commits, dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D65684
llvm-svn: 368101
This commit implements the fast dependency scanning mode in clang-scan-deps: the
preprocessing is done on files that are minimized using the dependency directives source minimizer.
A shared file system cache is used to ensure that the file system requests and source minimization
is performed only once. The cache assumes that the underlying filesystem won't change during the course
of the scan (or if it will, it will not affect the output), and it can't be evicted. This means that the
service and workers can be used for a single run of a dependency scanner, and can't be reused across multiple,
incremental runs. This is something that we'll most likely support in the future though.
Note that the driver still utilizes the underlying real filesystem.
This commit is also still missing the fast skipped PP block skipping optimization that I mentioned at EuroLLVM talk.
Additionally, the file manager is still not reused by the threads as well.
Differential Revision: https://reviews.llvm.org/D63907
llvm-svn: 368086
This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes.
Differential Revision: https://reviews.llvm.org/D64256
llvm-svn: 368072
Summary:
When searching for a declaration to be loaded the "lookup name" for every
other Decl is computed. If the USR can not be determined here should be
not an assert, instead skip this Decl.
Reviewers: martong
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65445
llvm-svn: 368020
There are times when we wish to explicitly control the C++ standard
library search paths used by the driver. For example, when we're
building against the Android NDK, we might want to use the NDK's C++
headers (which have a custom inline namespace) even if we have C++
headers installed next to the driver. We might also be building against
a non-standard directory layout and wanting to specify the C++ standard
library include directories explicitly.
We could accomplish this by passing -nostdinc++ and adding an explicit
-isystem for our custom search directories. However, users of our
toolchain may themselves want to use -nostdinc++ and a custom C++ search
path (libc++'s build does this, for example), and our added -isystem
won't respect the -nostdinc++, leading to multiple C++ header
directories on the search path, which causes build failures.
Add a new driver option -stdlib++-isystem to support this use case.
Passing this option suppresses adding the default C++ library include
paths in the driver, and it also respects -nostdinc++ to allow users to
still override the C++ library paths themselves.
It's a bit unfortunate that we end up with both -stdlib++-isystem and
-cxx-isystem, but their semantics differ significantly. -cxx-isystem is
unaffected by -nostdinc++ and is added to the end of the search path
(which is not appropriate for C++ standard library headers, since they
often #include_next into other system headers), while -stdlib++-isystem
respects -nostdinc++, is added to the beginning of the search path, and
suppresses the default C++ library include paths.
Differential Revision: https://reviews.llvm.org/D64089
llvm-svn: 367982
On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include.
Reorder RESOURCE_DIR/include to fix the search order problem.
(Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.)
gcc on musl has a similar search order:
```
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward
/usr/local/include
/usr/include/fortify
/usr/include
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include
```
This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include.
According to the maintainer of musl:
> musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident.
Reviewed by: phosek
Differential Revision: https://reviews.llvm.org/D65699
llvm-svn: 367981
The implementation of the OpenCL builtin currently library uses 2
different hacks to get to the corresponding IR intrinsics from the
source. This will allow removal of those.
This is the set that is currently used (minus a few vector ones).
llvm-svn: 367973
A buildbot got angry about this new test, with error messages like:
warn-nullchar-nullptr.c Line 16: use of undeclared identifier 'u'
It looks like this `u'c'` syntax was introduced in C11; I'm guessing
some bots may default to something before that. Let's see if explicitly
specifying the standard version makes it happy...
llvm-svn: 367947
This patch adds a warning that diagnoses comparisons of pointers to
'\0'. This is often indicative of a bug (e.g. the user might've
forgotten to dereference the pointer).
Patch by Elaina Guan!
Differential Revision: https://reviews.llvm.org/D65595
llvm-svn: 367940
This patch implements the code generation for OpenMP 5.0 declare mapper
(user-defined mapper) constructs. For each declare mapper, a mapper
function is generated. These mapper functions will be called by the
runtime and/or other mapper functions to achieve user defined mapping.
The design slides can be found at
https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx
Re-commit after revert in r367773 because r367755 changed the LLVM-IR
output such that a CHECK line failed.
Patch by Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D59474
llvm-svn: 367905
Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and
x86, 32 and 64-bit.
It turned out that this is due to different behaviour of logb depending on the C
standard compiled for, as documented on logb(3M):
RETURN VALUES
Upon successful completion, these functions return the exponent of x.
If x is subnormal:
o For SUSv3-conforming applications compiled with the c99 com-
piler driver (see standards(7)), the exponent of x as if x
were normalized is returned.
o Otherwise, if compiled with the cc compiler driver, -1022,
-126, and -16382 are returned for logb(), logbf(), and
logbl(), respectively.
Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those.
The following patch fixes this by following what gcc does, as corrected some time ago in
Fix use of Solaris values-Xc.o (PR target/40411)
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html.
Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D64793
llvm-svn: 367866
I have failures in this test because the grep @b gets confused by the
clang version including a repository name like this
!1 = !{!"clang version 10.0.0 (git@build-machine:llvm/llvm-monorepo.git fe958c0e8c89ec663c8e551936778e2cbb460154)"}
I considered something like grep -w but my understanding of the manpages
was that that isn't super portable. So I think it is easier to make
clang not to output that metadata using -fno-ident.
Differential Revision: https://reviews.llvm.org/D65635
llvm-svn: 367826
Summary:
It warns for for comments like
/** \pre \em */
where \em has no argument
This warning is enabled with the -Wdocumentation option.
Reviewers: gribozavr, rsmith
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64696
Patch by Mark de Wever.
llvm-svn: 367809
These "sanitizers" are hardened ABIs that are wholly orthogonal
to the SanitizerCoverage instrumentation.
Differential Revision: https://reviews.llvm.org/D65715
llvm-svn: 367799
This change introduces a pair of -fsanitize-link-runtime and
-fno-sanitize-link-runtime flags which can be used to control linking of
sanitizer runtimes. This is useful in certain environments like kernels
where existing runtime libraries cannot be used.
Differential Revision: https://reviews.llvm.org/D65029
llvm-svn: 367794
If a class or struct or union declaration contains a pragma that
is not valid in this context, compiler issues generic error like
"expected member name or ';' after declaration specifiers". With this
change the error tells that this pragma cannot appear in this declaration.
Differential Revision: https://reviews.llvm.org/D64932
llvm-svn: 367779
This patch implements the code generation for OpenMP 5.0 declare mapper
(user-defined mapper) constructs. For each declare mapper, a mapper
function is generated. These mapper functions will be called by the
runtime and/or other mapper functions to achieve user defined mapping.
The design slides can be found at
https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx
Patch by Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D59474
llvm-svn: 367773
For consistency with normal instructions and clarity when reading IR,
it's best to print the %0, %1, ... names of function arguments in
definitions.
Also modifies the parser to accept IR in that form for obvious reasons.
llvm-svn: 367755
Previously, debuginfo types are annotated to
IR builtin preserve_struct_access_index() and
preserve_union_access_index(), but not
preserve_array_access_index(). The debug info
is useful to identify the root type name which
later will be used for type comparison.
For user access without explicit type conversions,
the previous scheme works as we can ignore intermediate
compiler generated type conversions (e.g., from union types to
union members) and still generate correct access index string.
The issue comes with user explicit type conversions, e.g.,
converting an array to a structure like below:
struct t { int a; char b[40]; };
struct p { int c; int d; };
struct t *var = ...;
... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ...
Although BPF backend can derive the type of &(var->b[0]),
explicit type annotation make checking more consistent
and less error prone.
Another benefit is for multiple dimension array handling.
For example,
struct p { int c; int d; } g[8][9][10];
... __builtin_preserve_access_index(&g[2][3][4].d) ...
It would be possible to calculate the number of "struct p"'s
before accessing its member "d" if array debug info is
available as it contains each dimension range.
This patch enables to annotate IR builtin preserve_array_access_index()
with proper debuginfo type. The unit test case and language reference
is updated as well.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D65664
llvm-svn: 367724
Summary:
question-mark is not a BRE special character.
POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\?`
as used by rC366282 is undefined. This patch uses an ERE instead.
Reviewers: rnk, daltenty, xingxue, jasonliu
Reviewed By: rnk
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65668
llvm-svn: 367709
Summary:
The -Wparentheses warnings are enabled by default in clang but they are under
-Wall in gcc (gcc/c-family/c.opt). Some of the operator precedence warnings are
oftentimes criticized as noise (clang: default; gcc: -Wall). If a warning is
very controversial, it is probably not a good idea to enable it by default.
This patch disables the rather annoying ones:
-Wbitwise-op-parentheses, e.g. i & i | i
-Wlogical-op-parentheses, e.g. i && i || i
After this change:
```
* = enabled by default
-Wall
-Wparentheses
-Wlogical-op-parentheses
-Wlogical-not-parentheses*
-Wbitwise-op-parentheses
-Wshift-op-parentheses*
-Woverloaded-shift-op-parentheses*
-Wparentheses-equality*
-Wdangling-else*
```
-Woverloaded-shift-op-parentheses is typically followed by overload
resolution failure. We can instead improve the error message, and
probably delete -Woverloaded-shift-op-parentheses in the future. Keep it
for now because it gives some diagnostics.
Reviewers: akyrtzi, jyknight, rtrieu, rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65192
llvm-svn: 367690
Add PGO support at -O0 in the experimental new pass manager to sync the
behavior of the legacy pass manager.
Also change the test of gcc-flag-compatibility.c for more complete test:
(1) change the match string to "profc" and "profd" to ensure the
instrumentation is happening.
(2) add IR format proftext so that PGO use compilation is tested.
Differential Revision: https://reviews.llvm.org/D64029
llvm-svn: 367628
Summary:
This patch fixes the case where variables in different compilation units or the same compilation unit are under the declare target link clause AND have the same name.
This also fixes the name clash error that occurs when unified memory is activated.
The changes in this patch include:
- Pointers to internal variables are given unique names.
- Externally visible variables are given the same name as before.
- All pointer variables (external or internal) are weakly linked.
Reviewers: ABataev, jdoerfert, caomhin
Reviewed By: ABataev
Subscribers: lebedev.ri, guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64592
llvm-svn: 367613
Summary:
It allows discriminating between stack frames of the same call that is
called multiple times in a loop.
Thanks to Artem Dergachev for the great idea!
Reviewed By: NoQ
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65587
llvm-svn: 367608
clang/test/lit.cfg.py doesn't list .cc as test extension, so these
tests never ran.
Tweak one of the two tests to actually pass, now that it runs.
(The other one was already passing.)
llvm-svn: 367574
Summary:
Preivously we would only discard it if we failed to parse parameter lists.
If we do not consume the body, parser sees tokens inside directive. In
turn, this leads to spurious diagnostics and a crash in TokenBuffer, see
the added tests.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65517
llvm-svn: 367530
This is similar to r245139, but that only addressed dllexported classes.
It was still possible to run into the same problem with dllexported
members in an otherwise normal class (see bug). This uses the same
strategy to fix: delay defining the method until the whole class has
been parsed.
(The easiest way to see the ordering problem is in
Parser::ParseCXXMemberSpecification(): it calls
ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(),
which was trying to define the dllexport method. Now we delay it to
ActOnFinishCXXNonNestedClass() which is called after both of those.)
Differential revision: https://reviews.llvm.org/D65511
llvm-svn: 367520
Issue an warning when the code tries to do an implicit int -> float
conversion, where the float type ha a narrower significant than the
float type.
The new warning is controlled by flag -Wimplicit-int-float-conversion,
under -Wimplicit-float-conversion and -Wconversion. It is also silenced
when c++11 narrowing warning is issued.
Differential Revision: https://reviews.llvm.org/D64666
llvm-svn: 367497
The `InterlockedX_{acq,nf,rel}` functions deal with 32 bits which is long on
MSVC, but int on most other systems.
This also checks that `ReadStatusRegister` and `WriteStatusRegister` have
the correct type on aarch64-darwin.
Differential Revision: https://reviews.llvm.org/D64164
llvm-svn: 367479
Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it
easier to implement the transforms (and possibly other fneg transforms) in
1 place because we can always start the pattern match from fneg (either the
legacy binop or the new unop).
There's a secondary practical benefit seen in PR21914 and PR42681:
https://bugs.llvm.org/show_bug.cgi?id=21914https://bugs.llvm.org/show_bug.cgi?id=42681
...hoisting fneg rather than sinking seems to play nicer with LICM in IR
(although this change may expose analysis holes in the other direction).
1. The instcombine test changes show the expected neutral IR diffs from
reversing the order.
2. The reassociation tests show that we were missing an optimization
opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says
that all of these transforms are allowed (regardless of binop/unop
fneg version) because:
"For all other operations [besides copy/abs/negate/copysign], this
standard does not specify the sign bit of a NaN result."
In all of these transforms, we always have some other binop
(fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a
potential intermediate NaN operand.
(If that interpretation is wrong, then we must already have a bug in
the existing transforms?)
3. The clang tests shouldn't exist as-is, but that's effectively a
revert of rL367149 (the test broke with an extension of the
pre-existing fneg canonicalization in rL367146).
Differential Revision: https://reviews.llvm.org/D65399
llvm-svn: 367447
Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).
This patch adds support in both the clang frontend, and LLVM itself.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65500
llvm-svn: 367403
This adds support for parsing/emitting in IR the floating-point RISC-V
registers in inline assembly clobber lists.
Differential Revision: https://reviews.llvm.org/D64737
llvm-svn: 367399
If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
- if we could not build the type for the pattern on file (for some
reason). Here we should make the reason explicit. The actual problem
is otherwise circumvented as the warning is misleading, see [0] for
an example.
- if we could not build the type for the pattern because we do not
have a type on record, possible since D55483, we should not emit any
warning. See [1] for a legitimate problem.
This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.
Also see: PR40692
[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583
Differential Revision: https://reviews.llvm.org/D58091
llvm-svn: 367387
We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.
Fixes llvm.org/PR42779.
Differential revision: https://reviews.llvm.org/D65359
llvm-svn: 367367
UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently
FAILs on Solaris/x86_64:
clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11'
AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only),
which is what this patch does, together with updating another testcase.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64488
llvm-svn: 367351
Summary:
The cache recorded the wrong expansion location for all but the first
stringization. It seems uncommon to stringize the same macro argument
multiple times, so this cache doesn't seem that important.
Fixes PR39942
Reviewers: vsk, rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65428
llvm-svn: 367337
In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins.
Fixes https://llvm.org/pr42775
Differential Revision: https://reviews.llvm.org/D65403
llvm-svn: 367323
The Arm C Language Extensions for SVE document specifies that
__ARM_FEATURE_SVE should be set when the compiler supports SVE and
implements all the extensions described in the document.
This is currently not yet the case, so the feature should be disabled
until the compiler can provide all the extensions as described.
Reviewers: c-rhodes, rengolin, rovka, ktkachov
Reviewed By: rengolin
Differential Revision: https://reviews.llvm.org/D65404
llvm-svn: 367301
The `this` parameter of a thunk requires adjustment. Stop emitting an
incorrect dbg.declare pointing to the unadjusted pointer.
We could describe the adjusted value instead, but there may not be much
benefit in doing so as users tend not to debug thunks.
Robert O'Callahan reports that this matches gcc's behavior.
Fixes PR42627.
Differential Revision: https://reviews.llvm.org/D65035
llvm-svn: 367269
check the formal rules rather than seeing if the normal checks produce a
diagnostic.
This fixes the handling of C++2a extensions in lambdas in C++17 mode,
as well as some corner cases in earlier language modes where we issue
diagnostics for things other than not satisfying the formal constexpr
requirements.
llvm-svn: 367254
The as-options.s test writes to the build tree as of r367165. Some build systems configure this to be readonly, so this fails. Explicitly write to the output tree using `%t` to avoid this.
llvm-svn: 367253
While we implemented taint propagation rules for several
builtin/standard functions, there's a natural desire for users to add
such rules to custom functions.
A series of patches will implement an option that allows users to
annotate their functions with taint propagation rules through a YAML
file. This one adds parsing of the configuration file, which may be
specified in the commands line with the analyzer config:
alpha.security.taint.TaintPropagation:Config. The configuration may
contain propagation rules, filter functions (remove taint) and sink
functions (give a warning if it gets a tainted value).
I also added a new header for future checkers to conveniently read YAML
files as checker options.
Differential Revision: https://reviews.llvm.org/D59555
llvm-svn: 367190
Summary:
In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef).
In this patch, willreturn is annotated for LLVM intrinsics.
Reviewers: jdoerfert
Reviewed By: jdoerfert
Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64904
llvm-svn: 367184
Same kind of fix as in r367176, but for "RUN on line 76"
this time.
I'll ask for a post-commit review, to ensure this
matches the intention with the test added in r367165.
But I think this at least will make the buildbots a
little bit happier.
llvm-svn: 367182
This morally relands r365703 (and r365714), originally reviewed at
https://reviews.llvm.org/D64527, but with a different implementation.
Relanding the same approach with a fix for the revert reason got a bit
involved (see https://reviews.llvm.org/D65108) so use a simpler approach
with a more localized implementation (that in return duplicates code
a bit more).
This approach also doesn't validate flags for the integrated assembler
if the assembler step doesn't run.
Fixes PR42066.
Differential Revision: https://reviews.llvm.org/D65233
llvm-svn: 367165
This patch changes the following tests to run under the new pass manager only:
```
Clang :: CodeGen/avx512-reduceMinMaxIntrin.c (1 of 4)
Clang :: CodeGen/avx512vl-builtins.c (2 of 4)
Clang :: CodeGen/avx512vlbw-builtins.c (3 of 4)
Clang :: CodeGen/avx512f-builtins.c (4 of 4)
```
The new PM added extra bitcasts that weren't checked before. For
reduceMinMaxIntrin.c, the issue was mostly the alloca's being in a different
order. Other changes involved extra bitcasts, and differently ordered loads and
stores, but the logic should still be the same.
Differential revision: https://reviews.llvm.org/D65110
llvm-svn: 367157
This restores the use of `rm` instead of the non-portable `ln -n`. Such
use being the status quo for the 12-month period between rC334972 and
rC365414.
llvm-svn: 367147
The maximum alignment used by ARM arch
is 64bits, not 128.
This could cause overaligned memory
access for 128 bit neon vector that
have unpredictable behaviour.
This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668
Patch by: Diogo Sampaio(diogo.sampaio@arm.com)
Differential Revision: https://reviews.llvm.org/D65000
Change-Id: I5a62b766491f15dd51e4cfe6625929db897f67e3
llvm-svn: 367119
Summary:
Reduction variables are the variables, for which the private copies
must be created in the OpenMP regions. Then they are initialized with
the predefined values depending on the reduction operation. After exit
from the OpenMP region the original variable is updated using the
reduction value and the value of the original reduction variable.
Reviewers: NoQ
Subscribers: guansong, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65106
llvm-svn: 367116
SPIR targets need to have all functions be SPIR calling convention,
however the CXXABIs were just returning CC_C in all non-'this-CC' cases.
https://reviews.llvm.org/D65294
llvm-svn: 367103
This reverts commit r365985.
Prior to r365985, clang used to mark C union fields that have
non-trivial ObjC ownership qualifiers as unavailable if the union was
declared in a system header. r365985 stopped doing so, which caused the
swift compiler to crash when it tried to import a non-trivial union.
I have a patch that fixes the crash (https://reviews.llvm.org/D65256),
but I'm temporarily reverting the original patch until we can decide on
whether it's taking the right approach.
llvm-svn: 367076
This CL adds an optional warning to diagnose uses of the
`__builtin_alloca` family of functions. The use of these functions is
discouraged by many, so it seems like a good idea to allow clang to warn
about it.
Patch by Elaina Guan!
Differential Revision: https://reviews.llvm.org/D64883
llvm-svn: 367067
This reverts commit fd1274fa78cb0fd32cc1fa2e6f5bb8e62d29df19.
Add an explicit triple for the test which is pattern matching overly
aggressively.
llvm-svn: 367055
changes were made to the patch since then.
--------
[NewPM] Port Sancov
This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty.
Changes:
- Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over
functions and ModuleSanitizerCoverage for passing over modules.
- ModuleSanitizerCoverage exists for adding 2 module level calls to initialization
functions but only if there's a function that was instrumented by sancov.
- Added legacy and new PM wrapper classes that own instances of the 2 new classes.
- Update llvm tests and add clang tests.
llvm-svn: 367053
A placeholder instruction for use in generation of cleanup code for an
initializer list would not be emitted if the base class contained a
non-trivial destructor and the class contains no fields of its own. This
would be the case when using CTAD to deduce the template arguments for a
struct with an overloaded call operator, e.g.
```
template <class... Ts> struct ctad : Ts... {};
template <class... Ts> ctad(Ts...)->ctad<Ts...>;
```
and this class was initialized with a list of lambdas capturing by copy,
e.g.
```
ctad c {[s](short){}, [s](long){}};
```
In a release build the bug would manifest itself as a crash in the SROA
pass, however, in a debug build the following assert in CGCleanup.cpp
would fail:
```
assert(dominatingIP && "no existing variable and no dominating IP!");
```
By ensuring that a placeholder instruction is emitted even if there's no
fields in the class, neither the assert nor the crash is reproducible.
See https://bugs.llvm.org/show_bug.cgi?id=40771
Patch by Øystein Dale!
llvm-svn: 367042
Summary:
This is the first part of work announced in
"[RFC] Adding lifetime analysis to clang" [0],
i.e. the addition of the [[gsl::Owner(T)]] and
[[gsl::Pointer(T)]] attributes, which
will enable user-defined types to participate in
the lifetime analysis (which will be part of the
next PR).
The type `T` here is called "DerefType" in the paper,
and denotes the type that an Owner owns and a Pointer
points to. E.g. `std::vector<int>` should be annotated
with `[[gsl::Owner(int)]]` and
a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`.
[0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html
Reviewers: gribozavr
Subscribers: xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63954
llvm-svn: 367040
As passed in the Cologne meeting and treated by Core as a DR,
[[nodiscard]] was applied to constructors so that they can be diagnosed
in cases where the user forgets a variable name for a type.
The intent is to enable the library to start using this on the
constructors of scope_guard/lock_guard.
Differential Revision: https://reviews.llvm.org/D64914
llvm-svn: 367027
Summary:
r366702 added a set of new clang-cl -- specific openmp flags together with tests.
The way the newly added tests work is problematic: consider for example this
asertion:
```
// RUN: %clang_cl --target=x86_64-windows-msvc /openmp -### -- %s 2>&1 | FileCheck --check-prefix=CHECK-CC1-OPENMP %s
...
// CHECK-CC1-OPENMP: "-fopenmp"
```
It asserts that an `/openmp` flag should expand into `-fopenmp`. This however
depends on the default value of Clang's CLANG_DEFAULT_OPENMP_RUNTIME value.
Indeed, the code that adds `-fopenmp` to the output only does it if the default
runtime is `libomp` or `libiomp5`, not when it is `libgomp`.
I've updated the tests to not depend on the default value of this setting by
specifying the runtime to use explicitly in each assertion.
Reviewers: jdoerfert
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65272
llvm-svn: 367012
Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++
or -std=clc++/-std=CLC++.
This aligns with OpenCL C conversion and removes ambiguity
with OpenCL C++.
Differential Revision: https://reviews.llvm.org/D65102
llvm-svn: 367008
Summary:
When cross TU analysis is used it is possible that a macro expansion
is generated for a macro that is defined (and used) in other than
the main translation unit. To get the expansion for it the source
location in the original source file and original preprocessor
is needed.
Reviewers: martong, xazax.hun, Szelethus, ilya-biryukov
Reviewed By: Szelethus
Subscribers: mgorny, NoQ, ilya-biryukov, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64638
llvm-svn: 367006
This adds a new vectorize predication loop hint:
#pragma clang loop vectorize_predicate(enable)
that can be used to indicate to the vectoriser that all (load/store)
instructions should be predicated (masked). This allows, for example, folding
of the remainder loop into the main loop.
This patch will be followed up with D64916 and D65197. The former is a
refactoring in the loopvectorizer and the groundwork to make tail loop folding
a more general concept, and in the latter the actual tail loop folding
transformation will be implemented.
Differential Revision: https://reviews.llvm.org/D64744
llvm-svn: 366989
This reverts commit r366972 which broke the following tests:
Clang :: CXX/dcl.decl/dcl.init/dcl.init.list/p7-0x.cpp
Clang :: CXX/dcl.decl/dcl.init/dcl.init.list/p7-cxx11-nowarn.cpp
llvm-svn: 366979
Issue an warning when the code tries to do an implicit int -> float
conversion, where the float type ha a narrower significant than the
float type.
The new warning is controlled by flag -Wimplicit-int-float-conversion,
under -Wimplicit-float-conversion and -Wconversion.
Differential Revision: https://reviews.llvm.org/D64666
llvm-svn: 366972
Summary:
Move `-ftime-trace-granularity` option to frontend options. Without patch
this option is showed up in the help for any tool that links libSupport.
Reviewers: sammccall
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65202
llvm-svn: 366911
Adds the SVE vector and predicate registers to the list of known registers.
Patch by Kerry McLaughlin.
Reviewers: erichkeane, sdesmalen, rengolin
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D64739
llvm-svn: 366878
Clang :: Headers/max_align.c currently FAILs on 64-bit SPARC:
error: 'error' diagnostics seen but not expected:
File /vol/llvm/src/clang/dist/test/Headers/max_align.c Line 12: static_assert failed due to requirement '8 == _Alignof(max_align_t)' ""
1 error generated.
This happens because SuitableAlign isn't defined for SPARCv9 unlike SPARCv8
(which uses the default of 64 bits). gcc's sparc/sparc.h has
#define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64)
This patch sets SuitableAlign to match and updates the corresponding testcase.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64487
llvm-svn: 366820
Following up on the buildbot failures, this commits relaxes some tests:
instead of checking for specific IR output, it now ensures that the
underlying issue (the crash), and only that, doesn't happen.
llvm-svn: 366694
Summary:
Firstprivate variables are the variables, for which the private copies
must be created in the OpenMP regions and must be initialized with the
original values. Thus, we must report if the uninitialized variable is
used as firstprivate.
Reviewers: NoQ
Subscribers: guansong, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64765
llvm-svn: 366689
Modified the intrinsics
int_addressofreturnaddress,
int_frameaddress & int_sponentry.
This commit depends on the changes in rL366679
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D64563
llvm-svn: 366683
with '-mframe-pointer'
After D56351 and D64294, frame pointer handling is migrated to tri-state
(all, non-leaf, none) in clang driver and on the function attribute.
This patch makes the frame pointer handling cc1 option tri-state.
Reviewers: chandlerc, rnk, t.p.northover, MaskRay
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D56353
llvm-svn: 366645
Summary:
Add immutable WASM global `__tls_align` which stores the alignment
requirements of the TLS segment.
Add `__builtin_wasm_tls_align()` intrinsic to get this alignment in Clang.
The expected usage has now changed to:
__wasm_init_tls(memalign(__builtin_wasm_tls_align(),
__builtin_wasm_tls_size()));
Reviewers: tlively, aheejin, sbc100, sunfish, alexcrichton
Reviewed By: tlively
Subscribers: dschuff, jgravelle-google, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65028
llvm-svn: 366624
Summary:
Regular LTO modules do not need LTO Unit splitting, only ThinLTO does
(they must be consistently split into regular and Thin units for
optimizations such as whole program devirtualization and lower type
tests). In order to avoid spurious errors from LTO when combining with
split ThinLTO modules, always set this flag for regular LTO modules.
Reviewers: pcc
Subscribers: mehdi_amini, Prazek, inglorion, steven_wu, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65009
llvm-svn: 366623
Defining CLK_NULL_EVENT with a `(void*)` cast has the (unintended?)
side-effect that the address space will be fixed (as generic in OpenCL
2.0 mode). The consequence is that any target specific address space
for the clk_event_t type will not be applied.
It is not clear why the void pointer cast was needed in the first
place, and it seems we can do without it.
Differential Revision: https://reviews.llvm.org/D63876
llvm-svn: 366546
If the threadprivate variable is used in the copyin clause on inner
parallel directive with TLS support, we capture this variable in all
outer OpenMP scopes. It leads to the fact that in all scopes we're
working with the original variable, not the threadprivate copies.
llvm-svn: 366483
The RISC-V hard float calling convention requires the frontend to:
* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s)
* Track usage of GPRs and FPRs in order to gate the above, and to
determine when signext/zeroext attributes must be added to integer
scalars
This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.
Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.
Re-landed after backing out 366450 due to missed hunks.
Differential Revision: https://reviews.llvm.org/D60456
llvm-svn: 366480
Summary:
Add `__builtin_wasm_tls_base` so that LeakSanitizer can find the thread-local
block and scan through it for memory leaks.
Reviewers: tlively, aheejin, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64900
llvm-svn: 366475
variables.
Loop control variables are private in loop-based constructs and we shall
take this into account when generate the code for inner constructs.
Currently, those variables are reported as shared in many cases. Moved
the analysis of the data-sharing attributes of the loop control variable
to an early semantic stage to correctly handle their attributes.
llvm-svn: 366474
The RISC-V hard float calling convention requires the frontend to:
* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s) * Track usage of GPRs and FPRs in order to gate the
above, and to
determine when signext/zeroext attributes must be added to integer
scalars
This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.
Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.
Differential Revision: https://reviews.llvm.org/D60456
llvm-svn: 366450
Summary:
After r345152 cached completions started adding namespaces after
nested name specifiers, e.g. in `some_name::^`
The CCC_Symbol indicates the completed item cannot be a namespace (it is
described as being "a type, a function or a variable" in the comments).
Therefore, 'nested specifier' completions should only be added from cache
when the context is CCC_SymbolOrNewName (which roughly seems to indicate
that a nested name specifier is allowed).
Fixes https://bugs.llvm.org/show_bug.cgi?id=42646
Reviewers: kadircet, sammccall
Reviewed By: kadircet, sammccall
Subscribers: arphaman, nik, sammccall, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64918
llvm-svn: 366448
Reason: this commit causes crashes in the clang compiler when building
LLVM Support with libc++, see https://bugs.llvm.org/show_bug.cgi?id=42665
for details.
llvm-svn: 366429
Summary:
This patch does mainly three things:
1. It fixes a false positive error detection in Sema that is similar to
D62156. The error happens when explicitly calling an overloaded
destructor for different address spaces.
2. It selects the correct destructor when multiple overloads for
address spaces are available.
3. It inserts the expected address space cast when invoking a
destructor, if needed, and therefore fixes a crash due to the unmet
assertion in llvm::CastInst::Create.
The following is a reproducer of the three issues:
struct MyType {
~MyType() {}
~MyType() __constant {}
};
__constant MyType myGlobal{};
kernel void foo() {
myGlobal.~MyType(); // 1 and 2.
// 1. error: cannot initialize object parameter of type
// '__generic MyType' with an expression of type '__constant MyType'
// 2. error: no matching member function for call to '~MyType'
}
kernel void bar() {
// 3. The implicit call to the destructor crashes due to:
// Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed.
// in llvm::CastInst::Create.
MyType myLocal;
}
The added test depends on D62413 and covers a few more things than the
above reproducer.
Subscribers: yaxunl, Anastasia, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64569
llvm-svn: 366422
If dependent types appear in pointers or references we allow addr
space deduction because the addr space in template argument will
belong to the pointee and not the pointer or reference itself.
We also don't diagnose addr space on a function return type after
template instantiation. If any addr space for the return type was
provided on a template parameter this will be diagnosed during the
parsing of template definition.
Differential Revision: https://reviews.llvm.org/D62584
llvm-svn: 366417
Summary:
The problem is the default LoadExternal with no completer, which happens when
loading global results.
Reviewers: ilya-biryukov, nik
Subscribers: arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64864
llvm-svn: 366409
Remove dependency of malloc in implementation of mm_malloc function in PowerPC
intrinsics and alignment assumption on glibc.
Reviewed By: Hal Finkel
Differential Revision: https://reviews.llvm.org/D64850
llvm-svn: 366406
Summary:
Integer Set Library using retain-count based allocation which is not
modeled in MallocChecker.
Reviewed By: NoQ
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64680
llvm-svn: 366391
As discussed in D64780 the wording of this warning message is being
changed to say 'is not supported' instead of 'ignored', and the
diag ID itself is being changed to warn_cconv_not_supported.
llvm-svn: 366368
checkDecl is only valid for VarDecls or FieldDecls, since getCanonicalDecl
expects only these. Prevent other Decl kinds (such as CXXMethodDecls and
EnumConstantDecls) from entering and asserting.
Differential Revision: https://reviews.llvm.org/D64842
llvm-svn: 366336
Starting with Solaris 11.4 (which is now the required minimal version), Solaris does
support __cxa_atexit. This patch reflects that.
One might consider removing the affected tests altogether instead of inverting them,
as is done on other targets.
Besides, this lets two ASan tests PASS:
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64491
llvm-svn: 366305
There was a slight typo in r364352 that ended up causing our backend to
complain on some x86 Android builds. This CL fixes that.
Differential Revision: https://reviews.llvm.org/D64781
llvm-svn: 366276
Summary:
Thread local variables are placed inside a `.tdata` segment. Their symbols are
offsets from the start of the segment. The address of a thread local variable
is computed as `__tls_base` + the offset from the start of the segment.
`.tdata` segment is a passive segment and `memory.init` is used once per thread
to initialize the thread local storage.
`__tls_base` is a wasm global. Since each thread has its own wasm instance,
it is effectively thread local. Currently, `__tls_base` must be initialized
at thread startup, and so cannot be used with dynamic libraries.
`__tls_base` is to be initialized with a new linker-synthesized function,
`__wasm_init_tls`, which takes as an argument a block of memory to use as the
storage for thread locals. It then initializes the block of memory and sets
`__tls_base`. As `__wasm_init_tls` will handle the memory initialization,
the memory does not have to be zeroed.
To help allocating memory for thread-local storage, a new compiler intrinsic
is introduced: `__builtin_wasm_tls_size()`. This instrinsic function returns
the size of the thread-local storage for the current function.
The expected usage is to run something like the following upon thread startup:
__wasm_init_tls(malloc(__builtin_wasm_tls_size()));
Reviewers: tlively, aheejin, kripken, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64537
llvm-svn: 366272
The original commit is r366076. It is temporarily reverted (r366155)
due to test failure. This resubmit makes test more robust by accepting
regex instead of hardcoded names/references in several places.
This is a followup patch for https://reviews.llvm.org/D61809.
Handle unnamed bitfield properly and add more test cases.
Fixed the unnamed bitfield issue. The unnamed bitfield is ignored
by debug info, so we need to ignore such a struct/union member
when we try to get the member index in the debug info.
D61809 contains two test cases but not enough as it does
not checking generated IRs in the fine grain level, and also
it does not have semantics checking tests.
This patch added unit tests for both code gen and semantics checking for
the new intrinsic.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 366231
Summary:
Added support for analysis of if clauses in the OpenMP directives to be
able to check for the use of uninitialized variables.
Reviewers: NoQ
Subscribers: guansong, jfb, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: clang
Differential Revision: https://reviews.llvm.org/D64646
llvm-svn: 366211
I noticed that clang currently passes --dynamic-linker to ld. This has been the case
since Solaris 11 support was added initially back in 2012 by David Chisnall (r150580).
I couldn't find any patch submission, let alone a justification, for this, and it seems
completely useless: --dynamic-linker is a gld compatibility form of the option, the
native option being -I. First of all, however, the dynamic linker passed is simply the
default, so there's no reason at all to specify it in the first place.
This patch removes passing the option and adjusts the affected testcase accordingly.
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64493
llvm-svn: 366202
Summary:
This case is particularly important for clangd, as it is triggered after
inserting the snippet for variadic functions.
Reviewers: kadircet, ilya-biryukov
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64677
llvm-svn: 366200
The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined.
This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function.
The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used.
I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example).
make check-all didn't show any new failures.
[1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics
Differential Revision: https://reviews.llvm.org/D64495
llvm-svn: 366197
i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b:
* Bump the function_type_mismatch handler version, as its signature has changed.
* The function_type_mismatch handler can return successfully now, so
SanitizerKind::Function must be AlwaysRecoverable (like for
SanitizerKind::Vptr).
* But the minimal runtime would still unconditionally treat a call to the
function_type_mismatch handler as failure, so disallow -fsanitize=function in
combination with -fsanitize-minimal-runtime (like it was already done for
-fsanitize=vptr).
* Add tests.
Differential Revision: https://reviews.llvm.org/D61479
llvm-svn: 366186
Summary:
This is a reland of r366146, adding in the previously missing '--'
flag that prevents filenames from being interpreted as flags.
Original description:
This adds a -fthinlto-index= option to clang-cl, which allows it to
be used to drive ThinLTO backend passes. This allows clang-cl to be
used for distributed ThinLTO.
Tags: #clang
llvm-svn: 366165
Summary:
D28148 relaxed some checks for assigning { 0 } to a structure for all C
standards, but it failed to handle structures with non-integer
subobjects. Relax -Wmissing-braces checks for such structures, and add
some additional tests.
This fixes PR39931.
Patch By: al3xtjames
Reviewed By: Lekensteyn
Differential Revision: https://reviews.llvm.org/D61838
llvm-svn: 366163
Summary:
Preprocessor/init.c contains a line that explicitly checks for the
string
__VERSION__ "Clang{{.*}}
It's valid to have a toolchain configured to emit a vendor prefix
before the word Clang. e.g.
__VERSION__ "Vendor Clang{{.*}}
Subscribers: fedor.sergeev, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64772
llvm-svn: 366159
Summary:
This adds a -fthinlto-index= option to clang-cl, which allows it to
be used to drive ThinLTO backend passes. This allows clang-cl to be
used for distributed ThinLTO.
Reviewers: tejohnson, pcc, rnk
Subscribers: mehdi_amini, steven_wu, dexonsmith, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64458
llvm-svn: 366146
Summary:
Previously, passing -fthinlto-index= to clang required that bitcode
files be explicitly marked by -x ir. This change makes us detect files
with object file extensions as bitcode files when -fthinlto-index= is
present, so that explicitly marking them is no longer necessary.
Explicitly specifying -x ir is still accepted and continues to be part
of the test case to ensure we continue to support it.
Reviewers: tejohnson, rnk, pcc
Subscribers: mehdi_amini, steven_wu, dexonsmith, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64610
llvm-svn: 366127
Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.
It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.
The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.
Reviewers: pcc, hctim, vitalybuka, ostannard
Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64169
llvm-svn: 366123
This is a followup patch for https://reviews.llvm.org/D61809.
Handle unnamed bitfield properly and add more test cases.
Fixed the unnamed bitfield issue. The unnamed bitfield is ignored
by debug info, so we need to ignore such a struct/union member
when we try to get the member index in the debug info.
D61809 contains two test cases but not enough as it does
not checking generated IRs in the fine grain level, and also
it does not have semantics checking tests.
This patch added unit tests for both code gen and semantics checking for
the new intrinsic.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 366076
Summary:
Added support for analysis of if clauses in the OpenMP directives to be
able to check for the use of uninitialized variables.
Reviewers: NoQ
Subscribers: guansong, jfb, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64646
llvm-svn: 366068
Since pointee doesn't require context sensitive addr space deduction
it's easier to handle pointee of dependent types during templ
instantiation.
Differential Revision: https://reviews.llvm.org/D64400
llvm-svn: 366063
Pass NULL to pointer arg of __cxa_atexit if addr space
is not matching with its param. This doesn't align yet
with how dtors are generated that should be changed too.
Differential Revision: https://reviews.llvm.org/D62413
llvm-svn: 366059
gcc PowerPC supports 3 representations of long double:
* -mlong-double-64
long double has the same representation of double but is mangled as `e`.
In clang, this is the default on AIX, FreeBSD and Linux musl.
* -mlong-double-128
2 possible 128-bit floating point representations:
+ -mabi=ibmlongdouble
IBM extended double format. Mangled as `g`
In clang, this is the default on Linux glibc.
+ -mabi=ieeelongdouble
IEEE 754 quadruple-precision format. Mangled as `u9__ieee128` (`U10__float128` before gcc 8.2)
This is currently unavailable.
This patch adds -mabi=ibmlongdouble and -mabi=ieeelongdouble, and thus
makes the IEEE 754 quadruple-precision long double available for
languages supported by clang.
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D64283
llvm-svn: 366044
Teaches ARM::appendArchExtFeatures to account dependencies when processing
target features: i.e. when you say -march=armv8.1-m.main+mve.fp+nofp it
means mve.fp should get discarded too. (Split from D63936)
Differential Revision: https://reviews.llvm.org/D64048
llvm-svn: 366031
When processing the command line options march, mcpu and mfpu, we store
the implied target features on a vector. The change D62998 introduced a
temporary vector, where the processed features get accumulated. When
calling DecodeARMFeaturesFromCPU, which sets the default features for
the specified CPU, we certainly don't want to override the features
that have been explicitly specified on the command line. Therefore, the
default features should appear first in the final vector. This problem
became evident once I added the missing (unhandled) target features in
ARM::getExtensionFeatures.
Differential Revision: https://reviews.llvm.org/D63936
llvm-svn: 366027
Using noexcept multilib with -fno-exceptions can lead to significant
space savings when statically linking libc++abi because we don't need
all the unwinding and demangling code.
When compiling with ASan, we already get a lot of overhead from the
instrumentation itself, when statically linking libc++abi, that overhead
is even larger.
Having the noexcept variant for ASan can help significantly, we've seen
more than 50% size reduction in our system image, which offsets the cost
of having to build another multilib.
Differential Revision: https://reviews.llvm.org/D64140
llvm-svn: 365994
Some targets such as Python 2.7.16 still use VERSION in
their builds. Without VERSION defined, the source code
has syntax errors.
Reverting as it will probably break many other things.
Noticed by Sterling Augustine
llvm-svn: 365992
non-trivial C union types
This patch diagnoses uses of non-trivial C unions and structs/unions
containing non-trivial C unions in the following contexts, which require
default-initialization, destruction, or copying of the union objects,
instead of disallowing fields of non-trivial types in C unions, which is
what we currently do:
- function parameters.
- function returns.
- assignments.
- compound literals.
- block captures except capturing of `__block` variables by non-escaping
blocks.
- local and global variable definitions.
- lvalue-to-rvalue conversions of volatile types.
See the discussion in https://reviews.llvm.org/D62988 for more background.
rdar://problem/50679094
Differential Revision: https://reviews.llvm.org/D63753
llvm-svn: 365985
The default implementation of getSupportedSanitizers isn't able to turn
on the vptr sanitizer, and thus, any platform that runs this test will
fail with the error:
clang: error: unsupported option '-fsanitize=vptr' for target '<target>'
Patch by James Nagurne!
llvm-svn: 365981
Summary:
It has been introduced in 2011 for gcc compat:
ad1a4c6e89
it is probably time to remove it
Reviewers: rnk, dexonsmith
Reviewed By: rnk
Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64062
llvm-svn: 365962
Summary:
This paves the way for using passive segments in pthread builds, which
will make separate memory files unnecessary. Mutable globals are also
necessary for the upcoming implementation of TLS.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64586
llvm-svn: 365935
This patch series adds support for the next-generation arch13
CPU architecture to the SystemZ backend.
This includes:
- Basic support for the new processor and its features.
- Support for low-level builtins mapped to new LLVM intrinsics.
- New high-level intrinsics in vecintrin.h.
- Indicate support by defining __VEC__ == 10303.
Note: No currently available Z system supports the arch13
architecture. Once new systems become available, the
official system name will be added as supported -march name.
llvm-svn: 365933
Summary:
Patch makes D63967 effective for 32bit platforms and improves pattern
initialization there. It cuts size of 32bit binary compiled with
-ftrivial-auto-var-init=pattern by 2% (3% with -Os).
Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options)
```
master patch diff
Os pattern 7.915580e+05 7.698424e+05 -0.028387
O3 pattern 9.953688e+05 9.752952e+05 -0.019325
```
Zero vs Pattern on master
```
zero pattern diff
Os 7.689712e+05 7.915580e+05 0.031380
O3 9.744796e+05 9.953688e+05 0.021133
```
Zero vs Pattern with the patch
```
zero pattern diff
Os 7.689712e+05 7.698424e+05 0.000789
O3 9.744796e+05 9.752952e+05 0.000742
```
Reviewers: pcc, eugenis, glider, jfb
Reviewed By: jfb
Subscribers: hubert.reinterpretcast, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64597
llvm-svn: 365921
The "line" attribute is now the physical line within the source file for the location. A "presumedLine" attribute is printed when the presumed line number does not match the given source line number. We continue to not print repeated line information in subsequent source locations, but we track presumed and actual lines separately.
llvm-svn: 365919
Summary: This fixes broken tests when doing an out-of-source build that picks up a random .clang-format on the file system due to the default "file" style.
Reviewers: djasper, klimek, MyDeveloperDay, krasimir
Reviewed By: MyDeveloperDay
Subscribers: lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61001
llvm-svn: 365909
This fixes a bug where we would have an invalid JSON attribute (e.g., "value": inf). It also increases the precision of the values because they're not represented as approximate doubles with the host architecture's floating-point model.
llvm-svn: 365900
This patch makes the driver option -mlong-double-128 available for X86
and PowerPC. The CC1 option -mlong-double-128 is available on all targets
for users to test on unsupported targets.
On PowerPC, -mlong-double-128 uses the IBM extended double format
because we don't support -mabi=ieeelongdouble yet (D64283).
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D64277
llvm-svn: 365866
- Correctly display macro expansion and spelling locations.
- Use the same procedure to display location context call site locations.
- Display statement IDs for program points.
llvm-svn: 365861
Use a tri-state enum to represent shouldUseFramePointer() and
shouldUseLeafFramePointer().
This simplifies the logic and fixes PR9825:
-fno-omit-frame-pointer doesn't imply -mno-omit-leaf-frame-pointer.
and PR24003:
/Oy- /O2 should not omit leaf frame pointer: this matches MSVC x86-32.
(/Oy- is a no-op on MSVC x86-64.)
and:
when CC1 option -mdisable-fp-elim if absent, -momit-leaf-frame-pointer
can also be omitted.
The new behavior matches GCC:
-fomit-frame-pointer wins over -mno-omit-leaf-frame-pointer
-fno-omit-frame-pointer loses out to -momit-leaf-frame-pointer
The behavior makes lots of sense. We have 4 states:
- 00) leaf retained, non-leaf retained
- 01) leaf retained, non-leaf omitted (this is invalid)
- 10) leaf omitted, non-leaf retained (what -momit-leaf-frame-pointer was designed for)
- 11) leaf omitted, non-leaf omitted
"omit" options taking precedence over "no-omit" options is the only way
to make 3 valid states representable with -f(no-)?omit-frame-pointer and
-m(no-)?omit-leaf-pointer.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D64294
llvm-svn: 365860
Summary:
This helps with more efficient use of memset for pattern initialization
From @pcc prototype for -ftrivial-auto-var-init=pattern optimizations
Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options)
```
master patch diff
Os 8.238864e+05 8.238864e+05 0.0
O3 1.054797e+06 1.054797e+06 0.0
Os zero 8.292384e+05 8.292384e+05 0.0
O3 zero 1.062626e+06 1.062626e+06 0.0
Os pattern 8.579712e+05 8.338048e+05 -0.030299
O3 pattern 1.090502e+06 1.067574e+06 -0.020481
```
Zero vs Pattern on master
```
zero pattern diff
Os 8.292384e+05 8.579712e+05 0.036578
O3 1.062626e+06 1.090502e+06 0.025124
```
Zero vs Pattern with the patch
```
zero pattern diff
Os 8.292384e+05 8.338048e+05 0.003333
O3 1.062626e+06 1.067574e+06 0.003193
```
Reviewers: pcc, eugenis
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63967
llvm-svn: 365858
This reverts r365509 (git commit d088720eda)
This is a second revert[1] due to failures in internal test cases (shared offline) found during more thorough testing.
[1] Original patch commited as r364100, reverted as r364359, recommitted as r365509
llvm-svn: 365850
This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty.
Changes:
- Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over
functions and ModuleSanitizerCoverage for passing over modules.
- ModuleSanitizerCoverage exists for adding 2 module level calls to initialization
functions but only if there's a function that was instrumented by sancov.
- Added legacy and new PM wrapper classes that own instances of the 2 new classes.
- Update llvm tests and add clang tests.
Differential Revision: https://reviews.llvm.org/D62888
llvm-svn: 365838
File "clang/test/lit.cfg.py", line 186, in <module>
config.available_features.add('macos-sdk-' + macOSSDKVersion)
TypeError: must be str, not bytes
llvm-svn: 365832
Fixed the processing of the unsupported VLAs in the reduction clauses.
Used targetDiag if the diagnostics can be delayed and emit it
immediately if the target does not support VLAs and we're parsing target
directive with the reduction clauses.
llvm-svn: 365821
This flag is analoguous to other flags like -nostdlib or -nolibc
and could be used to disable linking of profile runtime library.
This is useful in certain environments like kernel, where profile
instrumentation is still desirable, but we cannot use the standard
runtime library.
llvm-svn: 365808
Summary:
Some OpenMP clauses rely on the values of the variables. If the variable
is not initialized and used in OpenMP clauses that depend on the
variables values, it should be reported that the uninitialized variable
is used in the OpenMP clause expression.
This patch adds initial processing for uninitialized variables in OpenMP
constructs. Currently, it checks for use of the uninitialized variables
in the structured blocks.
Reviewers: NoQ, Szelethus, dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet
Subscribers: rnkovacs, guansong, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64356
llvm-svn: 365786
by David Truby.
Summary:
This adds a zero length array section mapping for each pointer captured by a lambda that is used in a target region, as per section 2.19.7.1 of the OpenMP 5 specification.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: guansong, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64558
llvm-svn: 365777
An os_log_helper FunctionDecl may not have a body. Ignore these for the
purposes of debug entry value emission.
Fixes an assertion failure seen in a stage2 build of clang:
Assertion failed: (FD->hasBody() && "Functions must have body here"),
function analyzeParametersModification
llvm-svn: 365716
clang currently warns when passing flags for the assembler (e.g.
-Wa,-mbig-obj) to an invocation that doesn't run the assembler (e.g.
-E).
At first sight, that makes sense -- the flag really is unused. But many
other flags don't have an effect if no assembler runs (e.g.
-fno-integrated-as, -ffunction-sections, and many others), and those
currently don't warn. So this seems more like a side effect of how
CollectArgsForIntegratedAssembler() is implemented than like an
intentional feature.
Since it's a bit inconvenient when debugging builds and adding -E,
always call CollectArgsForIntegratedAssembler() to make sure assembler
args always get claimed. Currently, this affects only these flags:
-mincremental-linker-compatible, -mimplicit-it= (on ARM), -Wa, -Xassembler
It does have the side effect that assembler options now need to be valid
even if -E is passed. Previously, `-Wa,-mbig-obj` would error for
non-coff output only if the assembler ran, now it always errors. This
too makes assembler flags more consistent with all the other flags and
seems like a progression.
Fixes PR42066.
Differential Revision: https://reviews.llvm.org/D64527
llvm-svn: 365703
All the command lines are for 64-bit mode, but sometimes I compile
the tests in 32-bit mode to see what assembly we get and we need
to skip these to do that.
llvm-svn: 365668
To enable a new implicit kernel argument,
increased the number of argument bytes from 48 to 56.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D63756
llvm-svn: 365643
D63793 removed float-divide-by-zero from the "undefined" set but it
failed to add it to getSupportedSanitizers(), thus the sanitizer is
rejected by the driver:
clang-9: error: unsupported option '-fsanitize=float-divide-by-zero' for target 'x86_64-unknown-linux-gnu'
Also, add SanitizerMask::FloatDivideByZero to a few other masks to make -fsanitize-trap, -fsanitize-recover, -fsanitize-minimal-runtime and -fsanitize-coverage work.
Reviewed By: rsmith, vitalybuka
Differential Revision: https://reviews.llvm.org/D64317
llvm-svn: 365587
Summary:
It models the LLVM casts:
- `cast<>`
- `dyn_cast<>`
- `cast_or_null<>`
- `dyn_cast_or_null<>`
It has a very basic support without checking the `classof()` function.
(It reapplies the reverted 'llvm-svn: 365582' patch with proper test file.)
Reviewed By: NoQ
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64374
llvm-svn: 365585
Summary:
It models the LLVM casts:
- `cast<>`
- `dyn_cast<>`
- `cast_or_null<>`
- `dyn_cast_or_null<>`
It has a very basic support without checking the `classof()` function.
Reviewed By: NoQ
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64374
llvm-svn: 365582
The CCCR_Ignore action is only used for Microsoft calling conventions,
mainly because MSVC does not warn when a calling convention would be
ignored by the current target. This behavior is actually somewhat
important, since windows.h uses WINAPI (which expands to __stdcall)
widely. This distinction didn't matter much before the introduction of
__vectorcall to x64 and the ability to make that the default calling
convention with /Gv. Now, we can't just ignore __stdcall for x64, we
have to treat it as an explicit __cdecl annotation.
Fixes PR42531
llvm-svn: 365579
This patch ensures built-in functions are rewritten using the proper
parent declaration.
Existing tests are modified to run in C++ mode to ensure the
functionality works also with C++ for OpenCL while not increasing the
testing runtime.
llvm-svn: 365499
Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions.
Patch by Dominic Ferreira.
llvm-svn: 365498
The device should use the same float point representation as the host.
Previous patch fixed the handling of the sizes of the float point types,
but did not fixed the fp semantics. This patch makes target device to
use the host fp semantics. this is required for the correct data
transfer between host and device and correct codegen.
llvm-svn: 365485
In gcc PowerPC, long double has 3 mangling schemes:
-mlong-double-64: `e`
-mlong-double-128 -mabi=ibmlongdouble: `g`
-mlong-double-128 -mabi=ieeelongdouble: `u9__ieee128` (gcc <= 8.1: `U10__float128`)
The current useFloat128ManglingForLongDouble() bisection is not suitable
when we support -mlong-double-128 in clang (D64277). Replace
useFloat128ManglingForLongDouble() with getLongDoubleMangling() and
getFloat128Mangling() to allow 3 mangling schemes.
I also deleted the `getTriple().isOSBinFormatELF()` check (the Darwin
support has gone: https://reviews.llvm.org/D50988).
For x86, change the mangled code of __float128 from `U10__float128` to `g`. `U10__float128` was wrongly copied from PowerPC.
The test will be added to `test/CodeGen/x86-long-double.cpp` in D64277.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D64276
llvm-svn: 365480
For background of BPF CO-RE project, please refer to
http://vger.kernel.org/bpfconf2019.html
In summary, BPF CO-RE intends to compile bpf programs
adjustable on struct/union layout change so the same
program can run on multiple kernels with adjustment
before loading based on native kernel structures.
In order to do this, we need keep track of GEP(getelementptr)
instruction base and result debuginfo types, so we
can adjust on the host based on kernel BTF info.
Capturing such information as an IR optimization is hard
as various optimization may have tweaked GEP and also
union is replaced by structure it is impossible to track
fieldindex for union member accesses.
Three intrinsic functions, preserve_{array,union,struct}_access_index,
are introducted.
addr = preserve_array_access_index(base, index, dimension)
addr = preserve_union_access_index(base, di_index)
addr = preserve_struct_access_index(base, gep_index, di_index)
here,
base: the base pointer for the array/union/struct access.
index: the last access index for array, the same for IR/DebugInfo layout.
dimension: the array dimension.
gep_index: the access index based on IR layout.
di_index: the access index based on user/debuginfo types.
If using these intrinsics blindly, i.e., transforming all GEPs
to these intrinsics and later on reducing them to GEPs, we have
seen up to 7% more instructions generated. To avoid such an overhead,
a clang builtin is proposed:
base = __builtin_preserve_access_index(base)
such that user wraps to-be-relocated GEPs in this builtin
and preserve_*_access_index intrinsics only apply to
those GEPs. Such a buyin will prevent performance degradation
if people do not use CO-RE, even for programs which use
bpf_probe_read().
For example, for the following example,
$ cat test.c
struct sk_buff {
int i;
int b1:1;
int b2:2;
union {
struct {
int o1;
int o2;
} o;
struct {
char flags;
char dev_id;
} dev;
int netid;
} u[10];
};
static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr)
= (void *) 4;
#define _(x) (__builtin_preserve_access_index(x))
int bpf_prog(struct sk_buff *ctx) {
char dev_id;
bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id));
return dev_id;
}
$ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \
test.c >& log
The generated IR looks like below:
...
define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 {
%2 = alloca %struct.sk_buff*, align 8
%3 = alloca i8, align 1
store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45
call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49
call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50
call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51
%4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45
%5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45
%6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs(
%struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19
%7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons(
[10 x %union.anon]* %6, i32 1, i32 5), !dbg !53
%8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons(
%union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26
%9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53
%10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s(
%struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34
%11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52
%12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55
%13 = sext i8 %12 to i32, !dbg !54
call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56
ret i32 %13, !dbg !57
}
!19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20)
!26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27)
!34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35)
Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index
attached to instructions to provide struct/union debuginfo type information.
For &ctx->u[5].dev.dev_id,
. The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout.
. The "%7 = ..." represents array subscript "5".
. The "%8 = ..." represents union member "dev" with index 1 for DI layout.
. The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout.
Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and
examining all preserve_*_access_index calls, the debuginfo struct/union/array access index
can be achieved.
The intrinsics also contain enough information to regenerate codes for IR layout.
For array and structure intrinsics, the proper GEP can be constructed.
For union intrinsics, replacing all uses of "addr" with "base" should be enough.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61809
llvm-svn: 365438
For background of BPF CO-RE project, please refer to
http://vger.kernel.org/bpfconf2019.html
In summary, BPF CO-RE intends to compile bpf programs
adjustable on struct/union layout change so the same
program can run on multiple kernels with adjustment
before loading based on native kernel structures.
In order to do this, we need keep track of GEP(getelementptr)
instruction base and result debuginfo types, so we
can adjust on the host based on kernel BTF info.
Capturing such information as an IR optimization is hard
as various optimization may have tweaked GEP and also
union is replaced by structure it is impossible to track
fieldindex for union member accesses.
Three intrinsic functions, preserve_{array,union,struct}_access_index,
are introducted.
addr = preserve_array_access_index(base, index, dimension)
addr = preserve_union_access_index(base, di_index)
addr = preserve_struct_access_index(base, gep_index, di_index)
here,
base: the base pointer for the array/union/struct access.
index: the last access index for array, the same for IR/DebugInfo layout.
dimension: the array dimension.
gep_index: the access index based on IR layout.
di_index: the access index based on user/debuginfo types.
If using these intrinsics blindly, i.e., transforming all GEPs
to these intrinsics and later on reducing them to GEPs, we have
seen up to 7% more instructions generated. To avoid such an overhead,
a clang builtin is proposed:
base = __builtin_preserve_access_index(base)
such that user wraps to-be-relocated GEPs in this builtin
and preserve_*_access_index intrinsics only apply to
those GEPs. Such a buyin will prevent performance degradation
if people do not use CO-RE, even for programs which use
bpf_probe_read().
For example, for the following example,
$ cat test.c
struct sk_buff {
int i;
int b1:1;
int b2:2;
union {
struct {
int o1;
int o2;
} o;
struct {
char flags;
char dev_id;
} dev;
int netid;
} u[10];
};
static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr)
= (void *) 4;
#define _(x) (__builtin_preserve_access_index(x))
int bpf_prog(struct sk_buff *ctx) {
char dev_id;
bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id));
return dev_id;
}
$ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \
test.c >& log
The generated IR looks like below:
...
define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 {
%2 = alloca %struct.sk_buff*, align 8
%3 = alloca i8, align 1
store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45
call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49
call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50
call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51
%4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45
%5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45
%6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs(
%struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19
%7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons(
[10 x %union.anon]* %6, i32 1, i32 5), !dbg !53
%8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons(
%union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26
%9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53
%10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s(
%struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34
%11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52
%12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55
%13 = sext i8 %12 to i32, !dbg !54
call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56
ret i32 %13, !dbg !57
}
!19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20)
!26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27)
!34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35)
Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index
attached to instructions to provide struct/union debuginfo type information.
For &ctx->u[5].dev.dev_id,
. The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout.
. The "%7 = ..." represents array subscript "5".
. The "%8 = ..." represents union member "dev" with index 1 for DI layout.
. The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout.
Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and
examining all preserve_*_access_index calls, the debuginfo struct/union/array access index
can be achieved.
The intrinsics also contain enough information to regenerate codes for IR layout.
For array and structure intrinsics, the proper GEP can be constructed.
For union intrinsics, replacing all uses of "addr" with "base" should be enough.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 365435
This is a better fix for the problem fixed in r334972.
Also remove the rm'ing of the symlink destination that was there to
clean up the bots -- it's over a year later, bots should be happy now.
Differential Revision: https://reviews.llvm.org/D64301
llvm-svn: 365414
With this, `clang-cl /source-charset:utf-16 test.cc` now prints `invalid
value 'utf-16' in '/source-charset:utf-16'` instead of `invalid value
'utf-16' in '-finput-charset=utf-16'` before, and several other clang-cl
flags produce much less confusing output as well.
Fixes PR29106.
Since an arg and its alias can have different arg types (joined vs not)
and different values (because of AliasArgs<>), I chose to give the Alias
its own Arg object. For convenience, I just store the alias directly in
the unaliased arg – there aren't many arg objects at runtime, so that
seems ok.
Finally, I changed Arg::getAsString() to use the alias's representation
if it's present – that function was already documented as being the
suitable function for diagnostics, and most callers already used it for
diagnostics.
Implementation-wise, Arg::accept() previously used to parse things as
the unaliased option. The core of that switch is now extracted into a
new function acceptInternal() which parses as the _aliased_ option, and
the previously-intermingled unaliasing is now done as an explicit step
afterwards.
(This also changes one place in lld that didn't use getAsString() for
diagnostics, so that that one place now also prints the flag as the user
wrote it, not as it looks after it went through unaliasing.)
Differential Revision: https://reviews.llvm.org/D64253
llvm-svn: 365413
-mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}).
On many other targets, there will be an error:
error: unrecognized command line option '-mlong-double-64'
This patch makes the driver option -mlong-double-64 available for x86
and ppc. The CC1 option -mlong-double-64 is available on all targets for
users to test on unsupported targets.
LongDoubleSize is added as a VALUE_LANGOPT so that the option can be
shared with -mlong-double-128 when we support it in clang.
Also, make powerpc*-linux-musl default to use 64-bit long double. It is
currently the only supported ABI on musl and is also how people
configure powerpc*-linux-musl-gcc.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D64067
llvm-svn: 365412
In this mode the rewriter will only rewrite program points
and omit program states. Useful for understanding
the rough topology of the graph.
Differential Revision: https://reviews.llvm.org/D64264
llvm-svn: 365410
Instead of rewriting the whole graph, rewrite the leftmost path in the
graph. Useful for trimmed graphs that are still too large to display due
to multiple equivalent reports mixed into them.
Differential Revision: https://reviews.llvm.org/D64263
llvm-svn: 365409
On macOS, BOOL is a typedef for signed char, but it should never hold a value
that isn't 1 or 0. Any code that expects a different value in their BOOL should
be fixed.
rdar://51954400
Differential revision: https://reviews.llvm.org/D63856
llvm-svn: 365408
This is a fix for rG864949 which only disabled default construction and
assignment for lambdas with capture-defaults, where the C++2a draft
disables them for lambdas with any lambda-capture at all.
Patch by Logan Smith!
Differential Revision: https://reviews.llvm.org/D64058
llvm-svn: 365406
This reverts r365382 (git commit 8b1becf2e3)
Appears to regress this semi-reduced fragment of valid code from windows
SDK headers:
#define InterlockedIncrement64 _InterlockedIncrement64
extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend);
#pragma intrinsic(_InterlockedIncrement64)
unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) {
return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend);
}
Found on a buildbot here, but no mail was sent due to it already being
red:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067
llvm-svn: 365393
Summary:
During CTU analysis of complex projects, the loaded AST-contents of
imported TUs can grow bigger than available system memory. This option
introduces a threshold on the number of TUs to be imported for a single
TU in order to prevent such cases.
Differential Revision: https://reviews.llvm.org/D59798
llvm-svn: 365314
Summary:
Change the vuqadd scalar instrinsics to have the second argument as unsigned values, not signed,
accordingly to https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
So now the compiler correctly warns that a undefined negative float conversion is being done.
Reviewers: LukeCheeseman, john.brawn
Reviewed By: john.brawn
Subscribers: john.brawn, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64242
llvm-svn: 365300
Summary:
Change the vsqadd scalar instrinsics to have the second argument as signed values, not unsigned,
accordingly to https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
The existing unsigned argument can cause faulty code as negative float to unsigned conversion is
undefined, which llvm/clang optimizes away.
Reviewers: LukeCheeseman, john.brawn
Reviewed By: john.brawn
Subscribers: john.brawn, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64239
llvm-svn: 365298
Summary:
Prior to r329065, we used [-max, max] as the range of representable
values because LLVM's `fptrunc` did not guarantee defined behavior when
truncating from a larger floating-point type to a smaller one. Now that
has been fixed, we can make clang follow normal IEEE 754 semantics in this
regard and take the larger range [-inf, +inf] as the range of representable
values.
In practice, this affects two parts of the frontend:
* the constant evaluator no longer treats floating-point evaluations
that result in +-inf as being undefined (because they no longer leave
the range of representable values of the type)
* UBSan no longer treats conversions to floating-point type that are
outside the [-max, +max] range as being undefined
In passing, also remove the float-divide-by-zero sanitizer from
-fsanitize=undefined, on the basis that while it's undefined per C++
rules (and we disallow it in constant expressions for that reason), it
is defined by Clang / LLVM / IEEE 754.
Reviewers: rnk, BillyONeal
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63793
llvm-svn: 365272
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
I intend to improve the analyzer's bug reports by tracking condition
expressions.
01 bool b = messyComputation();
02 int i = 0;
03 if (b) // control dependency of the bug site, let's explain why we assume val
04 // to be true
05 10 / i; // warn: division by zero
I'll detail this heuristic in the followup patch, strictly related to this one
however:
* Create the new ControlDependencyCalculator class that uses llvm::IDFCalculator
to (lazily) calculate control dependencies for Clang's CFG.
* A new debug checker debug.DumpControlDependencies is added for lit tests
* Add unittests
Differential Revision: https://reviews.llvm.org/D62619
llvm-svn: 365197
Summary:
"ww" and "ws" are both constraint codes for VSX vector registers that
hold scalar double data. "ww" is preferred for float while "ws" is
preferred for double.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D64119
llvm-svn: 365106
Warnings can be promoted to errors.
But that shouldn't prevent us from getting the dependencies!
Differential Revision: https://reviews.llvm.org/D64149
llvm-svn: 365065
Transform clang::DominatorTree to be able to also calculate post dominators.
* Tidy up the documentation
* Make it clang::DominatorTree template class (similarly to how
llvm::DominatorTreeBase works), rename it to clang::CFGDominatorTreeImpl
* Clang's dominator tree is now called clang::CFGDomTree
* Clang's brand new post dominator tree is called clang::CFGPostDomTree
* Add a lot of asserts to the dump() function
* Create a new checker to test the functionality
Differential Revision: https://reviews.llvm.org/D62551
llvm-svn: 365028
https://bugs.llvm.org/show_bug.cgi?id=42041
In Clang's CFG, we use nullpointers to represent unreachable nodes, for
example, in the included testfile, block B0 is unreachable from block
B1, resulting in a nullpointer dereference somewhere in
llvm::DominatorTreeBase<clang::CFGBlock, false>::recalculate.
This patch fixes this issue by specializing
llvm::DomTreeBuilder::SemiNCAInfo::ChildrenGetter::Get for
clang::CFG to not contain nullpointer successors.
Differential Revision: https://reviews.llvm.org/D62507
llvm-svn: 365026
Add a label to nodes that have a bug report attached or on which
the analysis was generally interrupted.
Fix printing has_report and implement printing is_sink in the graph dumper.
Differential Revision: https://reviews.llvm.org/D64110
llvm-svn: 364992
When printing various statements that include braces (compound
statements, lambda expressions, statement-expressions, etc.),
replace the code between braces with '...'.
Differential Revision: https://reviews.llvm.org/D64104
llvm-svn: 364990
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.
The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.
rdar://44987528
Differential revision: https://reviews.llvm.org/D62825
llvm-svn: 364954
Due to RVO the target region of a function that returns an object by
value isn't necessarily a temporary object region; it may be an
arbitrary memory region. In particular, it may be a field of a bigger
object.
Make sure we don't invalidate the bigger object when said function is
evaluated conservatively.
Differential Revision: https://reviews.llvm.org/D63968
llvm-svn: 364870
The NonnullGlobalConstants checker models the rule "it doesn't make sense
to make a constant global pointer and initialize it to null"; it makes sure
that whatever it's initialized with is known to be non-null.
Ironically, annotating the type of the pointer as _Nonnull breaks the checker.
Fix handling of the _Nonnull annotation so that it was instead one more reason
to believe that the value is non-null.
Differential Revision: https://reviews.llvm.org/D63956
llvm-svn: 364869
This patch uses the new CDF_MaybeBuiltin flag to handle C library functions.
It's mostly an NFC/refactoring pass, but it does fix a bug in handling memset()
when it expands to __builtin___memset_chk() because the latter has
one more argument and memset() handling code was trying to match
the exact number of arguments. Now the code is deduplicated and there's
less room for mistakes.
Differential Revision: https://reviews.llvm.org/D62557
llvm-svn: 364868
Slightly cleanup emission of horizontal lines and unhardcode the title
for generic maps.
Differential Revision: https://reviews.llvm.org/D64041
llvm-svn: 364865
D60974 added tests which incorrectly assume that llvm-readelf is available. This is a bad assumption, it should instead declare the dependency explicitly in the tests.
llvm-svn: 364855
Previously, lambda captures were processed in the function called during
capturing the variables. It leads to the recursive functions calls and
may result in the compiler crash.
llvm-svn: 364820
Summary:
LLVM issues a warning if passed unknown target features. Neither I nor
@asb noticed this until after https://reviews.llvm.org/D63498 landed.
This patch stops passing the (unknown) "save-restore" target feature to
the LLVM backend, but continues to emit a warning if a driver asks for
`-msave-restore`. The default of assuming `-mno-save-restore` (and
emitting no warnings) remains.
Reviewers: asb
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64008
llvm-svn: 364777
If the variable is used in the OpenMP region implicitly, we need to
check the data-sharing attributes for such variables and generate
implicit clauses for them. Patch improves analysis of such variables for
better handling of data-sharing rules.
llvm-svn: 364683
`Selector::getIdentifierInfoForSlot` returns NULL if a slot has no
corresponding identifier. Add a boolean to the hash and a NULL check.
rdar://problem/51615164
Reviewers: rtrieu
Reviewed By: rtrieu
Subscribers: dexonsmith, cfe-commits, jkorous
Differential Revision: https://reviews.llvm.org/D63789
llvm-svn: 364664
Fixed handling of the data-sharing attributes for static members when
requesting top most attribute. Previously, it might return the incorrect
attributes for static members if they were overriden in the outer
constructs.
llvm-svn: 364655
According to the OpenMP 5.0 standard, the loop iteration variable in the associated
for-loop of a simd construct with just one associated for-loop may be
listed in a private, lastprivate, or linear clause with a linear-step
that is the increment of the associated for-loop. Also, the loop
teration variables in the associated for-loops of a simd construct with
multiple associated for-loops may be listed in a private or lastprivate
clause.
llvm-svn: 364650
The errors for incorrectly specified data-sharing attributes for simd
constructs must be emitted only for the explicitly provided clauses, not
the predetermined ones.
llvm-svn: 364647
Attach a unique DISubprogram to a function declaration that will be
used for call site debug info.
([7/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D60714
llvm-svn: 364502
If the type didn't exist, we used to emit a really bad error:
t.m:3:12: error: expected ')'
-(nullable NoSuchType)foo3;
^
rdar://50925632
llvm-svn: 364489
Kristof Umann