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
John McCall