| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For NetBSD 9 and later, it is the default. On older versions, only ARM
and AArch64 use it by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
includes search paths and diagnostics.
This is a recommit of r375322 and r375327 with a fix for the Windows test breakage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warnings. NFCI.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove one instance of a hardcoded output stream in
CompilerInstance::ExecuteAction. There are still other cases of output
being hard-coded to standard streams in ExecuteCompilerInvocation, but
this patch covers the case when no flags like -version or -help are
passed, namely the "X warnings and Y errors generated." diagnostic.
Differential Revision: https://reviews.llvm.org/D53768
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warnings. NFCI.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Use a forward declaration of DataLayout instead of including
DataLayout.h in clangs TargetInfo.h. This reduces include
dependencies toward DataLayout.h (and other headers such as
DerivedTypes.h, Type.h that is included by DataLayout.h).
Needed to move implemantation of TargetInfo::resetDataLayout
from TargetInfo.h to TargetInfo.cpp.
Reviewers: rnk
Reviewed By: rnk
Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69262
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375438 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Reduce include dependencies by no longer including Pass.h from
DataLayout.h. That include seemed irrelevant to DataLayout, as
well as being irrelevant to several users of DataLayout.
Reviewers: rnk
Reviewed By: rnk
Subscribers: mehdi_amini, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69261
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375436 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When building a precompiled header in -fmodule-format=obj (i.e.,
`-gmodules) in an absolute path, the locig in
CGDebugInfo::createCompileUnit would unconditionally append the source
directory to the -main-file-name. This patch avoids that behavior for
absolute paths.
rdar://problem/46045865
Differential Revision: https://reviews.llvm.org/D69213
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375423 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sometimes a global var is replaced by a different llvm value. clang use GetAddrOfGlobalVar to get the original llvm global variable.
For most targets, GetAddrOfGlobalVar returns either the llvm global variable or a bitcast of the llvm global variable.
However, for AMDGPU target, GetAddrOfGlobalVar returns the addrspace cast or addrspace cast plus bitcast of the llvm global variable.
To get the llvm global variable, these casts need to be stripped, otherwise there is assertion.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D69129
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which includes search paths and diagnostics." and "[Docs] Fix header level."
The test doesn't work on Windows. I'll fix it and recommit later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Kristóf Umann!
Differential Revision: https://reviews.llvm.org/D68591
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'self' was previously never tracked, but now it can be tracked
because it may be part of a condition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the
conditional operator. There's two main cases seen with this:
unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1;
unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2;
// Intended order of evaluation:
unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1);
unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2);
// Actual order of evaluation:
unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1;
unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2);
Differential Revision: https://reviews.llvm.org/D66043
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375326 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
includes search paths and diagnostics.
Differential Revision: https://reviews.llvm.org/D68528
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375322 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Taking a value and the bitwise-or it with a non-zero constant will always
result in a non-zero value. In a boolean context, this is always true.
if (x | 0x4) {} // always true, intended '&'
This patch creates a new warning group -Wtautological-bitwise-compare for this
warning. It also moves in the existing tautological bitwise comparisons into
this group. A few other changes were needed to the CFGBuilder so that all bool
contexts would be checked. The warnings in -Wtautological-bitwise-compare will
be off by default due to using the CFG.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666
Differential Revision: https://reviews.llvm.org/D66046
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Works on this dependency chain:
ArrayRef.h ->
Hashing.h -> --CUT--
Host.h ->
StringMap.h / StringRef.h
ArrayRef is very popular, but Host.h is rarely needed. Move the
IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are
more likely to need it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes an assertion failure in the case where an implicit conversion for a
function call involves an lvalue function conversion, and makes the AST for
initializations involving implicit lvalue function conversions more accurate.
Differential Revision: https://reviews.llvm.org/D66437
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: tra, sfantao, echristo
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69124
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
- HIP/CUDA host side needs to use device kernel symbol name to match the
device side binaries. Without a consistent naming between host- and
device-side compilations, it's risky that wrong device binaries are
executed. Consistent naming is usually not an issue until unnamed
types are used, especially the lambda. In this patch, the consistent
name mangling is addressed for the extended lambdas, i.e. the lambdas
annotated with `__device__`.
- In [Itanium C++ ABI][1], the mangling of the lambda is generally
unspecified unless, in certain cases, ODR rule is required to ensure
consisent naming cross TUs. The extended lambda is such a case as its
name may be part of a device kernel function, e.g., the extended
lambda is used as a template argument and etc. Thus, we need to force
ODR for extended lambdas as they are referenced in both device- and
host-side TUs. Furthermore, if a extended lambda is nested in other
(extended or not) lambdas, those lambdas are required to follow ODR
naming as well. This patch revises the current lambda mangle numbering
to force ODR from an extended lambda to all its parent lambdas.
- On the other side, the aforementioned ODR naming should not change
those lambdas' original linkages, i.e., we cannot replace the original
`internal` with `linkonce_odr`; otherwise, we may violate ODR in
general. This patch introduces a new field `HasKnownInternalLinkage`
in lambda data to decouple the current linkage calculation based on
mangling number assigned.
[1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html
Reviewers: tra, rsmith, yaxunl, martong, shafik
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68818
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds support for rewriting <, >, <=, and >= to a normal or reversed
call to operator<=>, for rewriting != to a normal or reversed call to
operator==, and for rewriting <=> and == to reversed forms of those same
operators.
Note that this is a breaking change for various C++17 code patterns,
including some in use in LLVM. The most common patterns (where an
operator== becomes ambiguous with a reversed form of itself) are still
accepted under this patch, as an extension (with a warning). I'm hopeful
that we can get the language rules fixed before C++20 ships, and the
extension warning is aimed primarily at providing data to inform that
decision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375306 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operator that is rewritten as a call to multiple other operators.
No functionality change yet: nothing creates these expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
even when nested in another class template specialization
Differential Revision: https://reviews.llvm.org/D63031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When the %m filename pattern is used, the filename is unique to each
image, so the cached value is wrong.
It struck me that the full filename isn't something that's recomputed
often, so perhaps it doesn't need to be cached at all. David Li pointed
out we can go further and just hide lprofCurFilename. This may regress
workflows that depend on using the set-filename API to change filenames
across all loaded DSOs, but this is expected to be very rare.
rdar://55137071
Differential Revision: https://reviews.llvm.org/D69137
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The '->' thing has always been confusing; the actual operation '->'
translates to a pointer dereference together with adding a FieldRegion,
but FieldRegion on its own doesn't imply an additional pointer
dereference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375281 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
One of the first attempts to reduce the size of the exploded graph dumps
was to skip the state dump as long as the state is the same as in all of
the predecessor nodes. With all the new facilities in place (node joining,
diff dumps), this feature doesn't do much, and when it does,
it's more harmful than useful. Let's remove it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375280 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The joined nodes now actually have the same state. That was intended
from the start but the original implementation turned out to be buggy.
Differential Revision: https://reviews.llvm.org/D69150
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375278 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The code `throw -1;` is currently formatted by clang-format as
`throw - 1;`. This diff adds a fix for this edge case and a test to check
for this in the future.
For context, I am looking into a related bug in the clang-formatting of
coroutine keywords: `co_yield -1;` is also reformatted in this manner
as `co_yield - 1;`. A later diff will add these changes and tests for the
`co_yield` and `co_return` keywords.
Patch by Jonathan Thomas (jonathoma)!
Reviewers: modocache, sammccall, Quuxplusone
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D69144
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375258 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Added trsing/semantics/codegen for combined construct master taskloop simd.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
r373922 added checks for a few tokens that, following an `)` make it
unlikely that the `)` is the closing paren of a cast expression. The
specific check for `tok::l_square` there introduced a regression for
casts of Obj-C calls, like:
```
(cast)[func arg]
```
From the tests added in r373922, I believe the `tok::l_square` case is added to
capture the case where a non-cast `)` is directly followed by an
attribute specifier, like:
```
int f(int x) [[noreturn]];
```
I've specialized the code to look for such attribute specifier instead
of `tok::l_square` in general. Also, I added a regression test and moved
the test cases added in r373922 to an already existing place documenting
other instances of historically misidentified casts.
Reviewers: MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69164
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375245 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is clang part of the patch. It adds -flto-unit flag for thin LTO
builds on Mac and PS4
Differential revision: https://reviews.llvm.org/D68950
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The sign extension proposal was motivated by a desire to not have
separate sign-extending atomic operations, so it is meant to be
enabled when threads are used.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69075
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ExplodedGraph nodes will now have a numeric identifier stored in them
which will keep track of the order in which the nodes were created
and it will be fully deterministic both accross runs and across machines.
This is extremely useful for debugging as it allows reliably setting
conditional breakpoints by node IDs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Because cast expressions have their own hierarchy, it's extremely useful
to have some information about what kind of casts are we dealing with.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In OpenMP constructs all counters are initialized and we should not emit
warnings about uninitialized privatized loop control variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375167 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If we can determined, that the global tid parameter can be used in the
function, better to use it rather than calling __kmpc_global_thread_num
function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375134 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer types.
For example, in Objective-C mode, the initialization of 'x' in:
```
@implementation MyType
+ (void)someClassMethod {
MyType *x = self;
}
@end
```
is correctly diagnosed with an incompatible-pointer-types warning, but
in Objective-C++ mode, it is not diagnosed at all -- even though
incompatible pointer conversions generally become an error in C++.
This patch fixes that oversight, allowing implicit conversions
involving Class only to/from unqualified-id, and between qualified and
unqualified Class, where the protocols are compatible.
Note that this does change some behaviors in Objective-C, as well, as
shown by the modified tests.
Of particular note is that assignment from from 'Class<MyProtocol>' to
'id<MyProtocol>' now warns. (Despite appearances, those are not
compatible types. 'Class<MyProtocol>' is not expected to have instance
methods defined by 'MyProtocol', while 'id<MyProtocol>' is.)
Differential Revision: https://reviews.llvm.org/D67983
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375125 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
regions.
The real global thread id must be passed to the outlined region instead
of the zero thread id.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PR43145 revealed two places where Clang was attempting to create a
bitcast without considering the address space of class types during
C++ class code generation.
Differential Revision: https://reviews.llvm.org/D68403
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375118 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D68581
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375104 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375101 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
output"
This test is failing on Windows bots, revert for now (will check the right fix and retry the patch).
Summary: This reverts commit 962ca076e51c25a7a08f4e0d329c65328a635bdb.
Reviewers: Bigcheese, jkorous, arphaman
Subscribers: dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69079
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375079 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Clang's -M mode includes these extra dependencies in its output and clang-scan-deps
should have equivalent behavior, so adding these extradeps to output just like
how its being done for ".d" file generation mode.
Reviewers: arphaman, dexonsmith, Bigcheese, jkorous
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69017
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375074 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attributes.
This reverts r375022 (git commit e2692b3bc0327606748b6d291b9009d2c845ced5)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Implement mangling for CSEs to match regular template-ids.
Reviewed as part of D41569 <https://reviews.llvm.org/D41569>.
Re-commit fixing failing test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: bruno, sammccall
Reviewed By: sammccall
Subscribers: jkorous, dexonsmith, arphaman, ributzka, cfe-commits
Differential Revision: https://reviews.llvm.org/D69011
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The expression of the priority clause must be captured in the combined
task-based directives, like 'parallel master taskloop' directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375026 91177308-0d34-0410-b5e6-96231b3b80d8
|
