Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331378
enabled for the host.
If the compilation for the host enables C++ exceptions, but they are not
supported by the device, we still need to allow the code with the
exception handling constructs outside of the target regions.
llvm-svn: 331372
Since we've been working on productizing the MachineOutliner in AArch64, it
makes sense to provide a more user-friendly way to enable it.
This allows users of AArch64 to enable the outliner using -foutline instead
of -mllvm -enable-machine-outliner. Other, less mature implementations (e.g,
x86-64) can still enable the pass using the -mllvm option.
Also add a test to make sure it works.
llvm-svn: 331370
Summary:
The filename is currently taken from the start of the path, while the
line and column are taken from the end of the path.
This didn't matter until cross-file path reporting was added.
Reviewers: george.karpenkov, dcoughlin, vlad.tsyrklevich
Reviewed By: george.karpenkov, vlad.tsyrklevich
Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D45611
llvm-svn: 331361
Some symbols are not allowed to be used as names on some targets. Patch
ries to unify the emission of the names of LLVM globals so they could be
used on different targets.
llvm-svn: 331358
Summary: Add `TaintBugVisitor` to the ArrayBoundV2, DivideZero, VLASize to be able to indicate where the taint information originated from.
Reviewers: NoQ, george.karpenkov, xazax.hun, a.sidorin
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D46007
llvm-svn: 331345
A @import targeting a top level module from a private module map file
(@import Foo_Private), would fail if there's any submodule declaration
around (module Foo.SomeSub) in the same private module map.
This happens because compileModuleImpl, when building Foo_Private, will
start with the private module map and will not parse the public one,
which leads to unsuccessful parsing of Foo.SomeSub, since top level Foo
was never parsed.
Declaring other submodules in the private module map is not common and
should usually be avoided, but it shouldn't fail to build. Canonicalize
compileModuleImpl to always look at the public module first, so that all
necessary information is available when parsing the private one.
rdar://problem/39822328
llvm-svn: 331322
It's possible for a header to be a symlink to another header. In this
case both will be represented by clang::FileEntry with the same UID and
they'll use the same clang::HeaderFileInfo.
If you include both headers and use some single-inclusion mechanism
like a header guard or #import, one header will get a FileChanged
callback, and another FileSkipped.
So that we get an accurate dependency file, we therefore need to also
implement the FileSkipped callback in dependency scanning.
Patch by Pete Cooper.
Reviewers: bruno, pete
Reviewed By: bruno
Subscribers: cfe-commits, jkorous, vsapsai
Differential Revision: https://reviews.llvm.org/D30881
llvm-svn: 331319
libclang exposes the type of 'int (Foo);' (a global variable of type int
called Foo) as CXType_Unexposed. This is because Clang represents Foo's
type as ParenType{BuiltinType{Int}}, and libclang does not handle
ParenType.
Make libclang return CXType_Int as the type of 'int (Foo);' by
unwrapping ParenType transparently.
Patch by Matt Glazar.
Differential Revision: https://reviews.llvm.org/D45713
llvm-svn: 331306
Both sides of this #if #include the same file. Drop the #if, leaving only the #include.
Patch by Matt Glazar.
Differential Revision: https://reviews.llvm.org/D45779
llvm-svn: 331305
Half-type mangling is accomplished following the method introduced by Erich
Keane for mangling _Float16. Updated the half.cl LIT test to cover this
particular case.
Patch By: vbridgers
Differential Revision: https://reviews.llvm.org/D46131
llvm-svn: 331263
devices.
If the function is an instantiation|specialization of the template and
is used in the device code, the definitions of such functions should be
emitted for the device.
llvm-svn: 331261
the build bots to healthy again without a full revert. As the
functionality added has nothing to do with linkage this seems unlikely
to represent a deep or interesting bug in the patch.
llvm-svn: 331245
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
Support for ObjC/C ODR-like semantics with structural equivalence
checking was added back in r306918. There enums are handled and also
checked for structural equivalence. However, at use time of
EnumConstantDecl, support was missing for preventing ambiguous
name lookup.
Add the missing bits for properly merging EnumConstantDecl.
rdar://problem/38374569
llvm-svn: 331232
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
We should not emit warning that the parameters are not marked as declare
target, these declaration are local and cannot be marked as declare
target.
llvm-svn: 331211
As suggested in the post-commit thread for rL331056, we should match these
clang options with the established vocabulary of the corresponding sanitizer
option. Also, the use of 'strict' is well-known for these kinds of knobs,
and we can improve the descriptive text in the docs.
So this intends to match the logic of D46135 but only change the words.
Matching LLVM commit to match this spelling of the attribute to follow shortly.
Differential Revision: https://reviews.llvm.org/D46236
llvm-svn: 331209
Emit error messages instead of compiler crashing when the target region
does not exist in the device code + fix crash when the location comes
from macros.
llvm-svn: 331195
Summary:
The getConstraintRegister method is used by semantic checking of
inline assembly statements in order to diagnose conflicts between
clobber list and input/output lists. Currently ARM and AArch64 don't
override getConstraintRegister, so conflicts between registers
assigned to variables in asm labels and clobber lists are not
diagnosed. Such conflicts can cause assertion failures in the back end
and even miscompilations.
This patch implements getConstraintRegister for ARM and AArch64
targets. Since these targets don't have single-register constraints,
the implementation is trivial and just returns the register specified
in an asm label (if any).
Reviewers: eli.friedman, javed.absar, thopre
Reviewed By: thopre
Subscribers: rengolin, eraman, rogfer01, myatsina, kristof.beyls, cfe-commits, chrib
Differential Revision: https://reviews.llvm.org/D45965
llvm-svn: 331164
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
Clang incorrectly applied the packed attribute to base classes. Per GCC's
documentation and as can be observed from its behavior, packed only applies to
members, not base classes.
This change is conditioned behind -fclang-abi-compat so that an ABI break can
be avoided by users if desired.
Differential Revision: https://reviews.llvm.org/D46218
llvm-svn: 331136
We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.
Differential revision: https://reviews.llvm.org/D45451
llvm-svn: 331098
During deserialization clang is currently missing the merging of
protocols into the canonical interface for the class extension.
This merging only currently happens during parsing and should also
be considered during deserialization.
rdar://problem/38724303
llvm-svn: 331063
As discussed in the post-commit thread for:
rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html )
We need a way to opt-out of a float-to-int-to-float cast optimization because too much
existing code relies on the platform-specific undefined result of those casts when the
float-to-int overflows.
The LLVM changes associated with adding this function attribute are here:
rL330947
rL330950
rL330951
Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that
catches this problem:
rL330958
Differential Revision: https://reviews.llvm.org/D46135
llvm-svn: 331041
The ACLE spec which describes these intrinsics hasn't been published yet, but
this is based on the final draft which will be published soon, and these have
already been implemented by GCC.
Differential revision: https://reviews.llvm.org/D46109
llvm-svn: 331039
This adds a pre-defined macro to test if the compiler has support for the
v8.2-A dot rpoduct intrinsics in AArch32 mode.
The AAcrh64 equivalent has already been added by rL330229.
The ACLE spec which describes this macro hasn't been published yet, but this is
based on the final internal draft, and GCC has already implemented this.
Differential revision: https://reviews.llvm.org/D46108
llvm-svn: 331038
SPIR-V encodes the read_only and write_only access qualifiers of pipes,
so separate LLVM IR types are required to target SPIR-V. Other backends
may also find this useful.
These new types are `opencl.pipe_ro_t` and `opencl.pipe_wo_t`, which
replace `opencl.pipe_t`.
This replaces __get_pipe_num_packets(...) and __get_pipe_max_packets(...)
which took a read_only pipe with separate versions for read_only and
write_only pipes, namely:
* __get_pipe_num_packets_ro(...)
* __get_pipe_num_packets_wo(...)
* __get_pipe_max_packets_ro(...)
* __get_pipe_max_packets_wo(...)
These separate versions exist to avoid needing a bitcast to one of the
two qualified pipe types.
Patch by Stuart Brady.
Differential Revision: https://reviews.llvm.org/D46015
llvm-svn: 331026
function if a function delegates to another function.
Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.
This reapplies r331016, which was reverted in r331019 because it caused
an assertion to fail in EmitDelegateCallArg on a windows bot. I made
changes to EmitDelegateCallArg so that it doesn't try to deactivate
cleanups for structs that have trivial destructors (cleanups for those
structs are never pushed to the cleanup stack in EmitParmDecl).
rdar://problem/39194693
Differential Revision: https://reviews.llvm.org/D45382
llvm-svn: 331020
function if a function delegates to another function.
Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.
rdar://problem/39194693
Differential Revision: https://reviews.llvm.org/D45382
llvm-svn: 331016
Avoid crash when the sub-expression of operator delete[] is of array type.
This is not the same as simply using a delete[] syntax.
We're still not properly calling destructors in this case in the analyzer.
Differential Revision: https://reviews.llvm.org/D46146
llvm-svn: 331014
template arguments.
This fixes some cases where we'd incorrectly accept "A::template B" when B is a
kind of template that requires template arguments (in particular, a variable
template or a concept).
llvm-svn: 331013
These builtins can't be handled by the backend on 64-bit targets. So error up front instead of throwing an isel error.
Fixes PR37225
Differential Revision: https://reviews.llvm.org/D46132
llvm-svn: 330987
Implementation of `InputArgList` assumes its field `ArgStrings` contains
strings for each argument exactly in the same order. This condition was
broken when arguments from config file and from invocation were merged.
This change fixes https://bugs.llvm.org/show_bug.cgi?id=37196 (Clang
config files can crash argument handling).
llvm-svn: 330926
On AVX512F targets we'll produce an emulated sequence using 3 pmuludqs with shifts and adds. On AVX512DQ we'll use vpmulld.
Fixes PR37140.
llvm-svn: 330923
a preceding 'template' keyword.
We only diagnose in the dependent case (wherein we used to crash). Another bug
prevents the diagnostic from appearing in the non-template case.
llvm-svn: 330894
If 'A' is a C++ aggregate with a reference field of type 'C', in code like
A a = { C() };
C() is lifetime-extended by 'a'. The analyzer wasn't expecting this pattern and
crashing. Additionally, destructors aren't added in the CFG for this case,
so for now we shouldn't be inlining the constructor for C().
Differential Revision: https://reviews.llvm.org/D46037
llvm-svn: 330882
Supporting additional rules for parsing ISA string.
- RISC-V ISA strings must be lowercase.
E.g.: rv32IMC is not supported, rv32imc is correct.
- Multi-letter extensions are to be separated by a single
underscore '_'. The extension prefix counts as a letter.
This means extensions that start with 's', 'sx' and 'sx'
are all multi-letter.
E.g.:
xasb is a single non-standard extension named 'xasb'
xa_sb are two extensions, the non-standard user level extension
'xa', and the supervisor level extension 'sb'.
- Standard user-level extensions are specified following
a canonical order, according to Table 22.1 in
RISC-V User-Level ISA V2.2.
- Non-standard user-level 'x' extensions,
standard supervisor-level 's' extensions and
non-standard supervisor-level 'sx' extensions
are also specified following a canonical order according
to Table 22.1 in RISC-V User-Level ISA V2.2:
'x' extensions, follwed by 's' extensions and then 'sx' extensions.
- Extensions might have a version number.
Underscores may be used to separate ISA subset components to
improve readability and to provide disambiguation.
E.g.: rv32i2_m3_a1_f2_d2
- Version numbers are divided into major and minor numbers,
separated by a 'p'. If the minor version is 0, then 'p0' can
be omitted.
- Additional checks for dependent extensions and invalid
extensions combinations.
E.g.:
'e' requires rv32
'e' can't be combined with 'f' nor 'd'
'q' requires rv64
- TODO items have also been marked with comments in the code.
Reviewers: asb, kito-cheng
Reviewed By: asb
Subscribers: edward-jones, mgrang, zzheng, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, shiva0217, cfe-commits
Differential Revision: https://reviews.llvm.org/D45284
llvm-svn: 330880
Normally the analyzer begins path-sensitive analysis from functions within
the main file, even though the path is allowed to go through any functions
within the translation unit.
When a recent version of WebKit is compiled, the "unified sources" technique
is used, that assumes #including multiple code files into a single main file.
Such file would have no functions defined in it, so the analyzer wouldn't be
able to find any entry points for path-sensitive analysis.
This patch pattern-matches unified file names that are similar to those
used by WebKit and allows the analyzer to find entry points in the included
code files. A more aggressive/generic approach is being planned as well.
Differential Revision: https://reviews.llvm.org/D45839
llvm-svn: 330876
Fixed directory separators in tests to be compatible with both
Windows and !Windows.
This reverts commit aa423850afa4c16a53c4c492fe254dcad3d5a53e.
llvm-svn: 330873
If -no-canonical-prefixes isn't used, the clang executable name used
is the one of the actual executable, not the name of the symlink that
the user invoked.
In these cases, the target prefix was overridden based on the clang
executable name. (On the other hand the implicit -target option
that such a symlink adds, is added as an actual command line parameter
in tools/driver/driver.cop, before resolving the symlink and finding
the actual clang executable.
Use the original ClangNameParts (set from argv[0] in
tools/driver/driver.cpp) if it seems to be initialized propery.
All existing tests of this feature used -no-canonical-prefixes
(possibly because it also makes the driver look in the directory
of the symlink instead of the directory of the executable); add
another one that uses --config-user-dir= to specify the directory
instead. (For actual users of such symlinks, outisde of the test
suite, the directory is probably the same for both.)
This makes this feature work more like what the documentation
describes.
Differential Revision: https://reviews.llvm.org/D45964
llvm-svn: 330871
Passing the features in random order will lead to unpredictable results
when some of the features are related (like the architecture-version
features on ARM).
It might be possible to fix this particular case in the ARM target code,
to avoid adding overlapping target features. But we should probably be
sorting in any case: the behavior shouldn't depend on StringMap's
hashing algorithm.
Differential Revision: https://reviews.llvm.org/D46030
llvm-svn: 330861
There are only a few cases of importing a frienddecl which is currently supported.
This patch aims to improve the friend import process.
Set FriendObjectKind in case of decls, insert friend into the friend chain
correctly, checks structurally equivalent in a more advanced manner.
Test cases added as well.
llvm-svn: 330847
Summary:
The example that was broken before (^ designates completion points):
class Foo {
Foo() : fie^ld^() {} // no completions were provided here.
int field;
};
To fix it we don't cut off lexing after an identifier followed by code
completion token is lexed. Instead we skip the rest of identifier and
continue lexing.
This is consistent with behavior of completion when completion token is
right before the identifier.
Reviewers: sammccall, aaron.ballman, bkramer, sepavloff, arphaman, rsmith
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44932
llvm-svn: 330833
This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly.
See the test file to get a sense of the basic parsing that this patch supports.
There is much more work to be done before concepts are usable...
Thanks Changyu!
llvm-svn: 330794
HIP is a language similar to CUDA (https://github.com/ROCm-Developer-Tools/HIP/blob/master/docs/markdown/hip_kernel_language.md ).
The language syntax is very similar, which allows a hip program to be compiled as a CUDA program by Clang. The main difference
is the host API. HIP has a set of vendor neutral host API which can be implemented on different platforms. Currently there is open source
implementation of HIP runtime on amdgpu target (https://github.com/ROCm-Developer-Tools/HIP).
This patch adds support of input kind and language standard hip.
When hip file is compiled, both LangOpts.CUDA and LangOpts.HIP is turned on. This allows compilation of hip program as CUDA
in most cases and only special handling of hip program is needed LangOpts.HIP is checked.
This patch also adds support of kernel launching of HIP program using HIP host API.
When -x hip is not specified, there is no behaviour change for CUDA.
Patch by Greg Rodgers.
Revised and lit test added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D44984
llvm-svn: 330790
Note diagnostic pieces are an additional way of highlighting code sections to
the user. They aren't part of the normal path diagnostic sequence. They can
also be attached to path-insensitive reports.
Notes are already supported by the text output and scan-build.
Expanding our machine-readable plist output format to be able to represent notes
opens up the possibility for various analyzer GUIs to pick them up.
Patch by Umann Kristóf!
Differential Revision: https://reviews.llvm.org/D45407
llvm-svn: 330766
For example, given:
void fn() {
enum __attribute__((deprecated)) T *p;
}
-ast-print produced:
void fn() {
enum T __attribute__((deprecated(""))) *p;
}
-ast-print on that produced:
void fn() {
enum T *p __attribute__((deprecated("")));
}
The attribute is on enum T in the first case, but it's on p in the
other cases.
Details:
Within enum declarations, enum attributes were always printed after
the tag and any member list. When no member list was present but the
enum was a type specifier in a variable declaration, the attribute
then applied to the variable not the enum, changing the semantics.
This patch fixes that by always printing attributes between the enum's
keyword and tag, as clang already does for structs, unions, and
classes.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D45456
llvm-svn: 330722
Summary:
Make completion behave consistently no matter if it is run at the
start, in the middle or at the end of an identifier that happens to
be a keyword or a macro name. Since completion is often ran on
incomplete identifiers, they may turn into keywords by accident.
For example, we should produce same results for all of these
completion points:
// ^ is completion point.
^class
cla^ss
class^
Previously clang produced different results for the last case (as if
the completion point was after a space: `class ^`).
This change also updates some offsets in tests that (unintentionally?)
relied on the old behavior.
Reviewers: sammccall, bkramer, arphaman, aaron.ballman
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45887
llvm-svn: 330717
This patch introduces the ability to test an arbitrary sequence of imports
between a given set of virtual source files. This should finally allow
us to write simple tests and fix annoying issues inside ASTImporter
that cause failures in CSA CTU. This is done by refactoring
ASTImporterTest functions and introducing `testImportSequence` facility.
As a side effect, `testImport` facility was generalized a bit more. It
should now allow import of non-decl AST nodes; however, there is still no
test using this ability.
As a "test for test", there is also a fix for import anonymous TagDecls
referred by typedef. Before this patch, the setting of typedef for anonymous
structure was delayed; however, this approach misses the corner case if
an enum constant is imported directly. In this patch, typedefs for
anonymous declarations are imported right after the anonymous declaration
is imported, without any delay.
Thanks to Adam Balogh for suggestions included into this patch.
Differential Revision: https://reviews.llvm.org/D44079
llvm-svn: 330704
Previously it would only accept a string as a GCC version if it had
either two components and no suffix, or three components with an
optional suffix.
Debian and ubuntu provided mingw compilers have lib/gcc/target entries
like "5.3-posix" and "5.3-win32". This doesn't try to make any specific
preference between them (other than lexical sorting of the suffix).
Differential Revision: https://reviews.llvm.org/D45505
llvm-svn: 330696
All attributes have a source range associated with it. However, implicit
attributes are added by the compiler, and not added because the user
wrote something in the input. So no token type should be set to
CXCursor_*Attr.
The problem was visible when a class gets marked by e.g.
MSInheritanceAttr, which has the full CXXRecordDecl's range as its
own range. The effect of marking that range as CXCursor_UnexposedAttr
was that all cursors for the record decl, including all child decls,
would become CXCursor_UnexposedAttr.
llvm-svn: 330692
The unmasked versions already didn't have this restrction. I don't think gcc or icc limit these to 64-bit mode so we shouldn't either.
llvm-svn: 330681
This makes it return the right result in a couple of edge cases. The
wide versions always do the comparison on the underlying wchar_t type.
llvm-svn: 330656
Summary:
It seems there isn't much enthusiasm for `-wtest` D45685.
This is more conservative version, which i had in the very first
revision of D44883, but that 'erroneously' got removed because of the review.
**Based on some [irc] discussions, it must really be documented that
we want all the new diagnostics to have their own flags, to ease
rollouts, transitions, etc.**
Please do note that i'm only adding `-Wno-self-assign-overloaded`,
but not `-Wno-self-assign-field-overloaded`, because i'm honestly
not aware of any false-positives from the `-field` variant,
but i can just as easily add it if wanted.
https://reviews.llvm.org/D44883#1068561
Reviewers: dblaikie, aaron.ballman, thakis, rjmccall, rsmith
Reviewed By: dblaikie
Subscribers: Quuxplusone, chandlerc, cfe-commits
Differential Revision: https://reviews.llvm.org/D45766
llvm-svn: 330651
Some buildbots seems to have problems with the CHECKs in
test/Frontend/ftime-report-template-decl.cpp.
I this the problem is that the order in which timers are printed
is based on consumed wall time. So there is no guarantee in which
order the timers are printed.
This patch uses CHECK-DAG instead of CHECK to make the test
case less sensitive to the actual time used by the different
passes.
The (sometimes) failing test cases where introduced in trunk@330571.
llvm-svn: 330622
NVPTX target.
When generating the wrapper function for the offloading region, we need
to call the outlined function and cast the arguments correctly to follow
the ABI. Usually, variables captured by value are casted to `uintptr_t`
type. But this should not performed for the variables with pointer type.
llvm-svn: 330620
Printing of ConcreteInts with size >64 bits resulted in assertion failure
in get[Z|S]ExtValue() because these methods are only allowed to be used
with integers of 64 max bit width. This patch fixes the issue.
llvm-svn: 330605
When rebasing https://reviews.llvm.org/D40898 with GCC 5.4 on Solaris 11.4, I ran
into a few instances of
In file included from /vol/llvm/src/compiler-rt/local/test/asan/TestCases/Posix/asan-symbolize-sanity-test.cc:19:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/string:40:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:59:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/move.h:57:
/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/type_traits:311:39: error: __float128 is not supported on this target
struct __is_floating_point_helper<__float128>
^
during make check-all. The line above is inside
#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
template<>
struct __is_floating_point_helper<__float128>
: public true_type { };
#endif
While the libstdc++ header indicates support for __float128, clang does not, but
should. The following patch implements this and fixed those errors.
Differential Revision: https://reviews.llvm.org/D41240
llvm-svn: 330572
If an atomic variable is misaligned (and that suspicion is why Clang emits
libcalls at all) the runtime support library will have to use a lock to safely
access it, with potentially very bad performance consequences. There's a very
good chance this is unintentional so it makes sense to issue a warning.
Also give it a named group so people can promote it to an error, or disable it
if they really don't care.
llvm-svn: 330566
Some targets need special LLVM calling convention for CUDA kernel.
This patch does that through a TargetCodeGenInfo hook.
It only affects amdgcn target.
Patch by Greg Rodgers.
Revised and lit tests added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D45223
llvm-svn: 330447
Summary:
By default Clang outputs its version (including git commit hash, in
case of trunk builds) into object and assembly files. It might be
useful to have an option to disable this, especially for debugging
purposes.
This patch implements new command line flags -Qn and -Qy (the names
are chosen for compatibility with GCC). -Qn disables output of
the 'llvm.ident' metadata string and the 'producer' debug info. -Qy
(enabled by default) does the opposite.
Reviewers: faisalv, echristo, aprantl
Reviewed By: aprantl
Subscribers: aprantl, cfe-commits, JDevlieghere, rogfer01
Differential Revision: https://reviews.llvm.org/D45255
llvm-svn: 330442
nvcc generates a unique registration function for each object file
that contains relocatable device code. Unique names are achieved
with a module id that is also reflected in the function's name.
Differential Revision: https://reviews.llvm.org/D42922
llvm-svn: 330425
This patch updates AddGoldPlugin to pass stats-file to the Gold plugin,
if -save-stats is passed. It also moves the save-stats option handling
to a helper function tools::getStatsFileName.
Reviewers: tejohnson, mehdi_amini, compnerd
Reviewed By: tejohnson, compnerd
Differential Revision: https://reviews.llvm.org/D45771
llvm-svn: 330422
Loop condition variables, eg.
while (shared_ptr<int> P = getIntPtr()) { ... })
weren't handled in r324794 because they don't go through the common
CFGBuilder::VisitDeclStmt method. Which means that they regressed
after r324800.
Fix the regression by duplicating the necessary construction context scan in
the loop visiting code.
Differential Revision: https://reviews.llvm.org/D45706
llvm-svn: 330382
If a pointer cast fails (evaluates to an UnknownVal, i.e. not implemented in the
analyzer) and such cast is in fact the last use of the pointer, the pointer
symbol is no longer referenced by the program state and a leak is
(mis-)diagnosed.
"Escape" the pointer upon a failed cast, i.e. inform the checker that we can no
longer reliably track it.
Differential Revision: https://reviews.llvm.org/D45698
llvm-svn: 330380
This implements support for the previously ignored flag
`-falign-functions`. This allows the frontend to request alignment on
function definitions in the translation unit where they are not
explicitly requested in code. This is compatible with the GCC behaviour
and the ICC behaviour.
The scalar value passed to `-falign-functions` aligns functions to a
power-of-two boundary. If flag is used, the functions are aligned to
16-byte boundaries. If the scalar is specified, it must be an integer
less than or equal to 4096. If the value is not a power-of-two, the
driver will round it up to the nearest power of two.
llvm-svn: 330378
Function argument constructors (that are used for passing objects into functions
by value) are completely unlike temporary object constructors, but we were
treating them as such because they are also wrapped into a CXXBindTemporaryExpr.
This patch adds a partial construction context layer for call argument values,
but doesn't proceed to transform it into an actual construction context yet.
This is tells the clients that we aren't supporting these constructors yet.
Differential Revision: https://reviews.llvm.org/D45650
llvm-svn: 330377
r315736 added support for the misplaced CF_RETURNS_RETAINED annotation on
CFRetain() wrappers. It works by trusting the function's name (seeing if it
confirms to the CoreFoundation naming convention) rather than the annotation.
There are more false positives caused by users using a different naming
convention, namely starting the function name with "retain" or "release"
rather than suffixing it with "retain" or "release" respectively.
Because this isn't according to the naming convention, these functions
are usually inlined and the annotation is therefore ignored, which is correct.
But sometimes we run out of inlining stack depth and the function is
evaluated conservatively and then the annotation is trusted.
Add support for the "alternative" naming convention and test the situation when
we're running out of inlining stack depth.
rdar://problem/18270122
Differential Revision: https://reviews.llvm.org/D45117
llvm-svn: 330375
Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.
This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953
Reviewers: rsmith, arphaman, doug.gregor
Reviewed By: doug.gregor
Subscribers: doug.gregor, cfe-commits
Differential Revision: https://reviews.llvm.org/D44670
llvm-svn: 330338
The force_align_arg_pointer attribute was using a hardcoded 16-byte
alignment value which in combination with -mstack-alignment=32 (or
larger) would produce a misaligned stack which could result in crashes
when accessing stack buffers using aligned AVX load/store instructions.
Fix the issue by using the "stackrealign" function attribute instead
of using a hardcoded 16-byte alignment.
Patch By: Gramner
Differential Revision: https://reviews.llvm.org/D45812
llvm-svn: 330331
This is the patch that lowers x86 intrinsics to native IR
in order to enable optimizations.
Patch by tkrupa
Differential Revision: https://reviews.llvm.org/D44786
llvm-svn: 330323
have a non-trivial destructor.
This fixes a bug introduced in r328731 where CodeGen emits calls to
synthesized destructors for non-trivial C structs in C++ mode when the
struct passed to EmitCallArg doesn't have a non-trivial destructor.
Under Microsoft's ABI, ASTContext::isParamDestroyedInCallee currently
always returns true, so it's necessary to check whether the struct has a
non-trivial destructor before pushing a cleanup in EmitCallArg.
This fixes PR37146.
llvm-svn: 330304
Following: https://llvm.org/svn/llvm-project/cfe/trunk@329804
For C++17 the wording of [over.built] p4 excluded bool:
For every pair (T , vq), where T is an arithmetic type other than bool, there exist
candidate operator functions of the form
vq T & operator++(vq T &);
T operator++(vq T &, int);
Differential Revision: https://reviews.llvm.org/D45569
llvm-svn: 330254
After r300027 implicit builds might fail when updating the SDK on
darwin. Make validation of system headers default when implicit modules
is on and allow modules to be rebuild when system headers change.
rdar://problem/19767523
llvm-svn: 330240
Enables _Float16 on Windows by creating a mangling
mechanism in MicrosoftMangle. It accomplishes this by
mangling as a structure type of __clang::_Float16, similar
to how Complex works.
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D45738
llvm-svn: 330225
Summary:
A clang builtin for xray typed events. Differs from
__xray_customevent(...) by the presence of a type tag that is vended by
compiler-rt in typical usage. This allows xray handlers to expand logged
events with their type description and plugins to process traced events
based on type.
This change depends on D45633 for the intrinsic definition.
Reviewers: dberris, pelikan, rnk, eizan
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45716
llvm-svn: 330220
Summary:
Android sysroots contain libraries for each OS version, as well as a
handful of unversioned libraries in the typical multiarch directory.
Reviewers: srhines, eugenis, george.burgess.iv
Reviewed By: eugenis
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D45290
llvm-svn: 330213
Issue a warning when non-trivial C structs are copied or initialized by
calls to memset, bzero, memcpy, or memmove.
rdar://problem/36124208
Differential Revision: https://reviews.llvm.org/D45310
llvm-svn: 330202
register destructor functions annotated with __attribute__((destructor))
using __cxa_atexit or atexit.
Register destructor functions annotated with __attribute__((destructor))
calling __cxa_atexit in a synthesized constructor function instead of
emitting references to the functions in a special section.
The primary reason for adding this option is that we are planning to
deprecate the __mod_term_funcs section on Darwin in the future. This
feature is enabled by default only on Darwin. Users who do not want this
can use command line option 'fno_register_global_dtors_with_atexit' to
disable it.
rdar://problem/33887655
Differential Revision: https://reviews.llvm.org/D45578
llvm-svn: 330199
Summary:
The clang driver option -save-temps was not passed to the LTO config,
so when invoking the ThinLTO backends via clang during distributed
builds there was no way to get LTO to save temp files.
Getting this to work with ThinLTO distributed builds also required
changing the driver to avoid a separate compile step to emit unoptimized
bitcode when the input was already bitcode under -save-temps. Not only is
this unnecessary in general, it is problematic for ThinLTO backends since
the temporary bitcode file to the backend would not match the module path
in the combined index, leading to incorrect ThinLTO backend index-based
optimizations.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D45217
llvm-svn: 330194
Without these comments, by "luck" the contents of SomeKit's SKWidget.h
are precisely the same as SomeKitCore's SomeKitCore.h. This can create
havoc if anything canonicalizes on the inode and your filesystem assigns
a common inode to files with identical file content. Alternatively, if
your build system uses symlinks into a content-addressed-storage (as
Google's does), you end up with these files being symlinks to the same
file.
The end result is that Clang deduplicates them internally, and then
believes that the SomeKit framework includes the SomeKitCore.h header,
and does not include the SKWidget.h in SomeKit. This in turn results in
warnings in this test and eventually errors as Clang becomes confused
because the umbrella header for SomeKitCore has already been included
into another framework's module (SomeKit). Yay.
If anyone has a better idea about how to avoid this, I'm all ears.
Nothing other than causing the file content to change worked for me.
llvm-svn: 330184
Currently, the interaction between the triple, the CPU, and the
supported features is a mess: the driver edits the triple to indicate
the supported architecture version, and the LLVM backend uses this to
figure out what instructions are legal. This makes it difficult to
understand what's happening, and makes it impossible to LTO together two
modules with different computed architectures.
Instead of relying on triple rewriting to get the correct target
features, we should add the right target features explicitly.
Differential Revision: https://reviews.llvm.org/D45240
llvm-svn: 330169
Summary:
There are some functions/methods that run when the application launches
or the library loads. Those functions will run reguardless the OS
version as long as it satifies the minimum deployment target. Annotate
them with availability attributes doesn't really make sense because they
are essentially available on all targets since minimum deployment
target.
rdar://problem/36093384
Reviewers: arphaman, erik.pilkington
Reviewed By: erik.pilkington
Subscribers: erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D45699
llvm-svn: 330166
As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033
Any usage of a builtin function that uses a va_list by reference
will cause an assertion when redeclaring it.
After discussion in the review, it was concluded that the correct
way of accomplishing this fix is to make attempts to redeclare certain
builtins an error. Unfortunately, doing this limitation for all builtins
is likely a breaking change, so this commit simply limits it to
types with custom type checking and those that take a reference.
Two tests needed to be updated to make this work.
Differential Revision: https://reviews.llvm.org/D45383
llvm-svn: 330160
Global variables marked as declare target are allowed to be used in map
clauses. Patch fixes the crash of the compiler on the declare target
variables in map clauses.
llvm-svn: 330156
volatile array field is copied.
The crash occurs because method 'visitArray' passes a null FieldDecl to
method 'visit' and some of the methods called downstream expect a
non-null FieldDecl to be passed.
This reapplies r330151 with a fix to the test case.
rdar://problem/33599681
llvm-svn: 330155
framework module SomeKitCore {
...
export_as SomeKit
}
Given the module above, while generting autolink information during
codegen, clang should to emit '-framework SomeKitCore' only if SomeKit
was not imported in the relevant TU, otherwise it should use '-framework
SomeKit' instead.
rdar://problem/38269782
llvm-svn: 330152
volatile array field is copied.
The crash occurs because method 'visitArray' passes a null FieldDecl to
method 'visit' and some of the methods called downstream expect a
non-null FieldDecl to be passed.
rdar://problem/33599681
llvm-svn: 330151
When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code. This initial support only
handles standard thunk ordinals.
Differential Revision: https://reviews.llvm.org/D43838
llvm-svn: 330132
MIPS does not use PIC level 2 for historical reasons,
even with -fPIC/-mxgot/multigot options. This patch
prevents PIC to be set to level 2 for MIPS.
Differential Revision: https://reviews.llvm.org/D44381
llvm-svn: 330118
Summary:
`this` pointer is not an l-value, although we have modeled `CXXThisRegion` for `this` pointer, we can only bind it once, which is when we start to inline method. And this patch fixes https://bugs.llvm.org/show_bug.cgi?id=35506.
In addition, I didn't find any other cases other than loop-widen that could invalidate `this` pointer.
Reviewers: NoQ, george.karpenkov, a.sidorin, seaneveson, szepet
Reviewed By: NoQ
Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D45491
llvm-svn: 330095
When profiling is enabled and -exported_symbols_list is specified for
the Darwin linker, export the requisite set of profiling symbols.
rdar://39427167
llvm-svn: 330077
Expression rearrangement in SValBuilder (see rL329780) crashes with an assert if the type of the integer is different from the type of the symbol. This fix adds a check that prevents rearrangement in such cases.
Differential Revision: https://reviews.llvm.org/D45557
llvm-svn: 330064
`__has_include_next` requires correct DirectoryLookup for being
evaluated correctly. We were using Preprocessor::GetCurDirLookup() but
we were calling it after the preprocessor finished its work. And in this
case CurDirLookup is always nullptr which makes `__has_include_next`
behave as `__has_include`.
Fix by storing and using CurDirLookup when preprocessor enters a file,
not when we rewrite the includes.
rdar://problem/36305026
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D45603
llvm-svn: 330041
Summary:
This allows us to do the following:
clang -fxray-modes=none ... -fxray-modes=xray-basic
It's important to be able to do this in cases where we'd like to
specialise the configuration for the invocation of the compiler, in
various scripting environments.
This is related to llvm.org/PR37066, a follow-up to D45474.
Reviewers: eizan, kpw, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45610
llvm-svn: 329989
Summary:
This change addresses http://llvm.org/PR36926 by allowing users to pick
which instrumentation bundles to use, when instrumenting with XRay. In
particular, the flag `-fxray-instrumentation-bundle=` has four valid
values:
- `all`: the default, emits all instrumentation kinds
- `none`: equivalent to -fnoxray-instrument
- `function`: emits the entry/exit instrumentation
- `custom`: emits the custom event instrumentation
These can be combined either as comma-separated values, or as
repeated flag values.
Reviewers: echristo, kpw, eizan, pelikan
Reviewed By: pelikan
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D44970
llvm-svn: 329985
"-mllvm" options get parsed slightly earlier, and -arm-restrict-it is
only available if the ARM target is compiled in. Invoke "clang -cc1"
directly to avoid the issue.
llvm-svn: 329968
It means the same thing as -mllvm; there isn't any reason to have two
options which do the same thing.
Differential Revision: https://reviews.llvm.org/D45109
llvm-svn: 329965
This makes it consistent with libstdc++ and the other default
include directories.
If these headers are found in both locations and one isn't a
symlink to the other, this will cause errors due to libc++ headers
having wrapper headers for some standard C headers, wrappers that
do #include_next the actual one.
If the same libc++ standard C wrapper header exists in more than one
include directory before the real system one, the header include
guard will stop it from doing another #include_next to pick up the
real one, breaking things.
As this is a rather uncommon situation, this should be acceptable
and toolchain maintainers can adapt accordingly if necessary.
Also simplify some of the existing code with a local variable.
Differential Revision: https://reviews.llvm.org/D45500
llvm-svn: 329946
Summary: The logic was broken for Linux triples as it returns true in the switch for Triple.isOSLinux().
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: kito-cheng, shiva0217, cfe-commits
Differential Revision: https://reviews.llvm.org/D45237
llvm-svn: 329941
A previously missing intrinsic for an old instruction.
Reviewers: craig.topper, echristo
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45311
llvm-svn: 329937
I broke this test in D45498 when I changed the formatter to remove
spaces before Objective-C lightweight generics.
This fixes the test.
Test Plan:
% make -j16 check-llvm-tools-llvm-lit && ./bin/llvm-lit -sv ../llvm/tools/clang/test/Index/comment-objc-parameterized-classes.m
llvm-svn: 329921
Summary:
This patch adds two new diagnostics, which are off by default:
**-Wreturn-std-move**
This diagnostic is enabled by `-Wreturn-std-move`, `-Wmove`, or `-Wall`.
Diagnose cases of `return x` or `throw x`, where `x` is the name of a local variable or parameter, in which a copy operation is performed when a move operation would have been available. The user probably expected a move, but they're not getting a move, perhaps because the type of "x" is different from the return type of the function.
A place where this comes up in the wild is `stdext::inplace_function<Sig, N>` which implements conversion via a conversion operator rather than a converting constructor; see https://github.com/WG21-SG14/SG14/issues/125#issue-297201412
Another place where this has come up in the wild, but where the fix ended up being different, was
try { ... } catch (ExceptionType ex) {
throw ex;
}
where the appropriate fix in that case was to replace `throw ex;` with `throw;`, and incidentally to catch by reference instead of by value. (But one could contrive a scenario where the slicing was intentional, in which case throw-by-move would have been the appropriate fix after all.)
Another example (intentional slicing to a base class) is dissected in https://github.com/accuBayArea/Slides/blob/master/slides/2018-03-07.pdf
**-Wreturn-std-move-in-c++11**
This diagnostic is enabled only by the exact spelling `-Wreturn-std-move-in-c++11`.
Diagnose cases of "return x;" or "throw x;" which in this version of Clang *do* produce moves, but which prior to Clang 3.9 / GCC 5.1 produced copies instead. This is useful in codebases which care about portability to those older compilers.
The name "-in-c++11" is not technically correct; what caused the version-to-version change in behavior here was actually CWG 1579, not C++14. I think it's likely that codebases that need portability to GCC 4.9-and-earlier may understand "C++11" as a colloquialism for "older compilers." The wording of this diagnostic is based on feedback from @rsmith.
**Discussion**
Notice that this patch is kind of a negative-space version of Richard Trieu's `-Wpessimizing-move`. That diagnostic warns about cases of `return std::move(x)` that should be `return x` for speed. These diagnostics warn about cases of `return x` that should be `return std::move(x)` for speed. (The two diagnostics' bailiwicks do not overlap: we don't have to worry about a `return` statement flipping between the two states indefinitely.)
I propose to write a paper for San Diego that would relax the implicit-move rules so that in C++2a the user //would// see the moves they expect, and the diagnostic could be re-worded in a later version of Clang to suggest explicit `std::move` only "in C++17 and earlier." But in the meantime (and/or forever if that proposal is not well received), this diagnostic will be useful to detect accidental copy operations.
Reviewers: rtrieu, rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, Rakete1111, rsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43322
Patch by Arthur O'Dwyer.
llvm-svn: 329914
Summary:
Protocols that were being referenced but could not be fully realized were being emitted without `properties`/`optional_properties`. Since all v3 protocols must be 9 processor words wide, the lack of these fields is catastrophic for the runtime.
As an example, the runtime cannot know [here](https://github.com/gnustep/libobjc2/blob/master/protocol.c#L73) that `properties` and `optional_properties` are invalid.
Reviewers: rjmccall, theraven
Reviewed By: rjmccall, theraven
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D45305
llvm-svn: 329882
type.
Copy the code in ActOnStartOfFunctionDef that checks a function's return
type to ActOnStartOfObjCMethodDef. This fixes an assertion failure in
IRGen caused by an uninstantiated return type.
rdar://problem/38691818
llvm-svn: 329879
The WBNOINVD instruction writes back all modified
cache lines in the processor’s internal cache to main memory
but does not invalidate (flush) the internal caches.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43817
llvm-svn: 329848
When we enter a __finally block, the CGF's CurCodeDecl will be null
(because CodeGenFunction::StartFunction is given an empty GlobalDecl for
a __finally block), and so the dyn_cast here will result in an assertion
failure. Change it to dyn_cast_or_null to handle this case.
Differential Revision: https://reviews.llvm.org/D45523
llvm-svn: 329836
When NVPTX TARGET_BUILTIN specifies sm_XX or ptxYY as required feature,
consider those features available if we're compiling for GPU >= sm_XX or have
enabled PTX version >= ptxYY.
Differential Revision: https://reviews.llvm.org/D45061
llvm-svn: 329829
C++ [over.built] p4:
"For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form
VQ T& operator--(VQ T&);
T operator--(VQ T&, int);
"
The bool type is in position LastPromotedIntegralType in BuiltinOperatorOverloadBuilder::getArithmeticType::ArithmeticTypes, but addPlusPlusMinusMinusArithmeticOverloads() was expecting it at position 0.
Differential Revision: https://reviews.llvm.org/D44988
rdar://problem/34255516
llvm-svn: 329804
Since the range-based constraint manager (default) is weak in handling comparisons where symbols are on both sides it is wise to rearrange them to have symbols only on the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables the constraint manager to store a range m - n .. MAX_VALUE for the symbolic expression A - B. This can be used later to check whether e.g. A + k == B + l can be true, which is also rearranged to A - B == l - k so the constraint manager can check whether l - k is in the range (thus greater than or equal to m - n).
The restriction in this version is the the rearrangement happens only if both the symbols and the concrete integers are within the range [min/4 .. max/4] where min and max are the minimal and maximal values of their type.
The rearrangement is not enabled by default. It has to be enabled by using -analyzer-config aggressive-relational-comparison-simplification=true.
Co-author of this patch is Artem Dergachev (NoQ).
Differential Revision: https://reviews.llvm.org/D41938
llvm-svn: 329780
Summary:
This patch implements the `-fxray-modes=` flag which allows users
building with XRay instrumentation to decide which modes to pre-package
into the binary being linked. The default is the status quo, which will
link all the available modes.
For this to work we're also breaking apart the mode implementations
(xray-fdr and xray-basic) from the main xray runtime. This gives more
granular control of which modes are pre-packaged, and picked from
clang's invocation.
This fixes llvm.org/PR37066.
Note that in the future, we may change the default for clang to only
contain the profiling implementation under development in D44620, when
that implementation is ready.
Reviewers: echristo, eizan, chandlerc
Reviewed By: echristo
Subscribers: mgorny, mgrang, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45474
llvm-svn: 329772
This test ensures the popfd instruction in MS inline assembly can properly find a clobber name for the dirflag register. Previously the register was named 'DF', but it needs to be named 'dirflag' to match the name in the GCC register name list.
llvm-svn: 329738
Currently we always include PTX into the fatbin along
with the GPU code.It about doubles the size of the GPU binary
we need to carry in the executable. These options allow control
inclusion of PTX into GPU binary.
This patch does not change the defaults, though we may consider
making no-PTX the default in the future.
Differential Revision: https://reviews.llvm.org/D45495
llvm-svn: 329737
In `ParseDeclarationSpecifiers` for the code
class A typename A;
we were able to annotate token `kw_typename` because it refers to
existing type. But later during processing token `annot_typename` we
failed to `SetTypeSpecType` and exited switch statement leaving
annotation token unconsumed. The code after the switch statement failed
because it didn't expect a special token.
The fix is not to assume that switch statement consumes all special
tokens and consume any token, not just non-special.
rdar://problem/37099386
Reviewers: rsmith, arphaman
Reviewed By: rsmith
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D44449
llvm-svn: 329735
Alexey Bataev