context.
If the explicit template instantiation definition defined outside of the
target context, its vtable should not be marked as used. This is true
for other situations where the compiler want to emit vtables
unconditionally.
llvm-svn: 341570
Namely, print the likely macro name when it's used, and include the actual
computed sizes in the diagnostic message, which are sometimes not obvious.
rdar://43909200
Differential revision: https://reviews.llvm.org/D51697
llvm-svn: 341566
This recommits r341472, which was reverted due to test failures on macos bots.
The issue was that a macos target implies -glldb which, together with
this patch added a -gpubnames switch where there previously wasn't one.
The intentions of those checks was to check that -gpubnames is not
emitted by default so I add an explicit -ggdb arg to those command lines
to get same behavior on all platforms (the fact that -glldb *does* set
-gpubnames is tested by a separate test).
Differential Revision: https://reviews.llvm.org/D51576
llvm-svn: 341564
This reverts commit r341519, which generates debug info that causes
backend crashes. (with -split-dwarf-file)
Details in https://reviews.llvm.org/D50495
llvm-svn: 341549
Summary:
Negative arguments in kernel attributes are silently bitcast'ed to
unsigned, for example:
__attribute__((reqd_work_group_size(1, -1, 1)))
__kernel void k() {}
is a complete equivalent of:
__attribute__((reqd_work_group_size(1, 4294967294, 1)))
__kernel void k() {}
This is likely an error, so the patch forbids negative arguments in
several OpenCL attributes. Users who really want 4294967294 can still
use it as an unsigned representation.
Reviewers: Anastasia, yaxunl, bader
Reviewed By: Anastasia, yaxunl, bader
Subscribers: bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D50259
llvm-svn: 341539
Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.
After fixing PR37395.
After fixing problems in LiveDebugVariables.
Differential Revision: https://reviews.llvm.org/D45045
llvm-svn: 341519
destructors.
We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.
This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.
This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.
This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.
llvm-svn: 341499
This is a warning about using 'assign' instead of 'unsafe_unretained'
in Objective-C property declarations. It's off by default because there
isn't consensus in the Objective-C steering group that this is the right
thing to do, but we're nonetheless okay with adding it because there's a
substantial pool of Objective-C programmers who will appreciate the warning.
Patch by Alfred Zien!
llvm-svn: 341489
Summary:
This provides information about the macro definition. For example, it
can be used to compute macro USRs.
Reviewers: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51675
llvm-svn: 341476
Summary:
DWARF v5 accelerator tables provide a considerable performance
improvement for lldb and will make the default -glldb behavior same on
all targets (right now we emit apple tables on apple targets, but these
are not controlled by -gpubnames, only by -glldb).
Reviewers: dblaikie
Subscribers: probinson, clayborg, JDevlieghere, aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D51576
llvm-svn: 341472
This fixes formatting namespaces with preceding 'inline' and 'export' (Modules TS) specifiers.
This change fixes namespaces not being identified as such with preceding 'inline' or 'export' specifiers.
Motivation: I was experimenting with the Modules TS (-fmodules-ts) and found it would be useful if clang-format would correctly format 'export namespace'. While making the changes, I noticed that similar issues still exist with 'inline namespace', and addressed them as well.
Patch by Marco Elver!
Reviewers: klimek, djasper, owenpan, sammccall
Reviewed By: owenpan, sammccall
Subscribers: owenpan, cfe-commits
Differential Revision: https://reviews.llvm.org/D51036
llvm-svn: 341450
Summary:
Added support of creating a hardlink from one file to another file.
After a hardlink is added between two files, both file will have the same:
1. UniqueID (inode)
2. Size
3. Buffer
This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs.
Patch by Utkarsh Saxena!
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51359
llvm-svn: 341366
Load Hardening.
Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.
Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.
While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.
This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.
Differential Revision: https://reviews.llvm.org/D51157
llvm-svn: 341363
This reverts commit b4547c9cadd2f8adfe3f3182e4c56e466c5256cb.
Apparently git llvm push from the monorepo does not respect branches and
pushes the current branch to master.
llvm-svn: 341352
The code remains so that we can potentially reenable it in a point
release, but the driver will reject it. Several issues were raised
during testing that made it clear that this was not quite ready for
general consumption.
Approved by: Hans Wennborg
llvm-svn: 341350
Summary:
Some `Expr` classes set up default values for the `ExprBits` of `Stmt`. These
default values are then overwritten by the parser sometimes. One example is
`InitListExpr` which sets the value kind to be an rvalue in the ctor. However,
this bit may change after the `InitListExpr` is created. There may be other
expressions similar to `InitListExpr` in this sense, thus the safest solution
is to copy the expression bits.
The lack of copying `ExprBits` causes an assertion in the analyzer engine in a
specific case: Since the value kind is not imported, the analyzer engine
believes that the given InitListExpr is an rvalue, thus it creates a
nonloc::CompoundVal instead of creating memory region (as in case of an lvalue
reference).
Reviewers: a_sidorin, r.stahl, xazax.hun, a.sidorin
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D51533
llvm-svn: 341316
This patch fixes target linker emulation for aarch64 big endian.
aarch64_be_linux is not recognized by gnu ld. The equivalent emulation
mode supported by gnu ld is aarch64linuxb.
Patch by: Bharathi Seshadri
Reviewed by: Peter Smith
Differential Revision: https://reviews.llvm.org/D42930
llvm-svn: 341312
Summary:
Given the following kernel:
__kernel void foo() {
double d;
double4 dd;
}
and cl_khr_fp64 is disabled, the compilation would fail due to
the presence of 'double d', but when removed, it passes.
The expectation is that extended vector types of unsupported types
will also be unsupported.
The patch adds the check for this scenario.
Patch by: Ofir Cohen
Reviewers: bader, Anastasia, AlexeySotkin, yaxunl
Reviewed By: Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51296
llvm-svn: 341309
These aren't documented in the Intel Intrinsics Guide, but are supported by gcc and icc.
Includes these intrinsics:
_ktestc_mask8_u8, _ktestz_mask8_u8, _ktest_mask8_u8
_ktestc_mask16_u8, _ktestz_mask16_u8, _ktest_mask16_u8
_ktestc_mask32_u8, _ktestz_mask32_u8, _ktest_mask32_u8
_ktestc_mask64_u8, _ktestz_mask64_u8, _ktest_mask64_u8
llvm-svn: 341265
This adds:
_cvtmask8_u32, _cvtmask16_u32, _cvtmask32_u32, _cvtmask64_u64
_cvtu32_mask8, _cvtu32_mask16, _cvtu32_mask32, _cvtu64_mask64
_load_mask8, _load_mask16, _load_mask32, _load_mask64
_store_mask8, _store_mask16, _store_mask32, _store_mask64
These are currently missing from the Intel Intrinsics Guide webpage.
llvm-svn: 341251
This adds the following intrinsics:
_kshiftli_mask8
_kshiftli_mask16
_kshiftli_mask32
_kshiftli_mask64
_kshiftri_mask8
_kshiftri_mask16
_kshiftri_mask32
_kshiftri_mask64
llvm-svn: 341234
Summary:
Added option -gline-directives-only to support emission of the debug directives
only. It behaves very similar to -gline-tables-only, except that it sets
llvm debug info emission kind to
llvm::DICompileUnit::DebugDirectivesOnly.
Reviewers: echristo
Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D51177
llvm-svn: 341212
There are two types of dynamic initializer stubs. There's
`dynamic initializer for 'x''(void)
and
`dynamic initializer for `static Foo::Bar StaticDataMember''(void)
The second case is disambiguated from the first by the presence of
a ? after the operator code. So the first will appear something like
?__E<name> while the second will appear something like ?__E?<name>.
clang-cl was mangling these both the same though. This patch
matches behavior with cl.
Differential Revision: https://reviews.llvm.org/D51500
llvm-svn: 341117
The changes were breaking CUDA compilation.
Reverted revisions:
r340681 D50845
[CUDA/OpenMP] Define only some host macros during device compilation
r340772 D51312
[OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading
r340967 D51441
Add predefined macro __gnu_linux__ for proper aux-triple
llvm-svn: 341115
'declare target'.
All the functions, referenced in implicit|explicit target regions must
be emitted during code emission for the device.
llvm-svn: 341093
Return value of dyn_cast_or_null should be checked before use.
Otherwise we may put a null pointer into the map as a key and eventually
crash in checkDeadSymbols.
Differential Revision: https://reviews.llvm.org/D51385
llvm-svn: 341092
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 341082
AMDGPU target need -fvisibility hidden option for clang to
work around a limitation of no PLT support, otherwise there is compilation
error at -O0.
Differential Revision: https://reviews.llvm.org/D51434
llvm-svn: 341077
Object linking isn't supported, so it's not useful
to emit default visibility. Default visibility requires
relocations we don't yet support for functions compiled
in another translation unit.
WebAssembly already does this, although they insert these
arguments in a different place for some reason.
llvm-svn: 341033
ASTContext::applyObjCProtocolQualifiers will return a canonical type when given
a canonical type and an array of canonical protocols. If the protocols are not
canonical then the returned type is also not canonical. Since a canonical type is needed, canonicalize the returned type before using it. This later prevents
a type from having a non-canonical canonical type.
llvm-svn: 341013
Introduce a new MemRegion sub-class, CXXDerivedObjectRegion, which is
the opposite of CXXBaseObjectRegion, to represent such casts. Such region is
a bit weird because it is by design bigger than its super-region.
But it's not harmful when it is put on top of a SymbolicRegion
that has unknown extent anyway.
Offset computation for CXXDerivedObjectRegion and proper modeling of casts
still remains to be implemented.
Differential Revision: https://reviews.llvm.org/D51191
llvm-svn: 340984
Don't try to understand what's going on when there's a C++ method called eg.
CFRetain().
Refactor the checker a bit, to use more modern APIs.
Differential Revision: https://reviews.llvm.org/D50866
llvm-svn: 340982
The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.
Fixes a crash reported as pr37769.
Differential Revision: https://reviews.llvm.org/D50855
llvm-svn: 340977
The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.
Fixes pr37769.
Differential Revision: https://reviews.llvm.org/D50824
llvm-svn: 340975
Clang predefine macro __linx__ for aux-triple with Linux OS
but does not predefine macro __gnu_linux__. This causes
some compilation error for certain applications, e.g. Eigen.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D51441
llvm-svn: 340967
By making sure the returned value from getKnownSVal is consistent with
the value used inside expression engine.
PR38427
Differential Revision: https://reviews.llvm.org/D51252
llvm-svn: 340965
If the target construct can be executed in SPMD mode + it is a loop
based directive with static scheduling, we can use lightweight runtime
support.
llvm-svn: 340953
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340949
Since MinGW supports automatically importing external variables from
DLLs even without the DLLImport attribute, we shouldn't mark them
as DSO local unless we actually know them to be local for sure.
Keep marking thread local variables as DSO local.
Differential Revision: https://reviews.llvm.org/D51382
llvm-svn: 340941
Summary:
Resolve all relative paths before running the tool instead.
This fixes the usage of ClangTool in AllTUsExecutor. The executor will
try running multiple ClangTool instances in parallel with compile
commands that usually have the same working directory.
Changing working directory is a global operation, so we end up
changing working directory in the middle of running other actions,
which leads to spurious compile errors.
Reviewers: ioeric, sammccall
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51407
llvm-svn: 340937
Currently ident_t objects are created const when debug info is not
enabled, but the libittnotify libray in the OpenMP runtime writes to
the reserved_2 field (See __kmp_itt_region_forking in
openmp/runtime/src/kmp_itt.inl). Now create ident_t objects non-const.
Differential Revision: https://reviews.llvm.org/D51331
llvm-svn: 340934
ARM_FEATURE_DSP is already set for targets with the +dsp feature. In
the backend, this target feature is also used to represent the
availability of the of the instructions that the ACLE guard through
the __ARM_FEATURE_SIMD32 macro. We don't have any cores that
implement one and not the other, so set this macro for cores later
than V6 or for Cortex-M cores that the target parser, or user, reports
that the 'dsp' instructions are supported.
Differential Revision: https://reviews.llvm.org/D51093
llvm-svn: 340911
This adds the following intrinsics:
_kadd_mask64
_kadd_mask32
_kadd_mask16
_kadd_mask8
These are missing from the Intel Intrinsics Guide, but are implemented by both gcc and icc.
llvm-svn: 340879
OffloadBundlingJobAction constructor accepts a list of JobAction as inputs.
The host JobAction is the last one. The file type of OffloadBundlingJobAction
should be determined by the host JobAction (the last one) instead of the first
one.
Since HIP emits LLVM bitcode for device compilation, device JobAction has
different file type as host Job Action. This bug causes incorrect output file
extension for HIP.
This patch fixes it by using the last input JobAction (host JobAction) to determine
file type of OffloadBundlingJobAction.
Differential Revision: https://reviews.llvm.org/D51336
llvm-svn: 340873
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340860
It seems like an oversight that this check was not always enabled for
on-device or device simulator targets.
Differential Revision: https://reviews.llvm.org/D51239
llvm-svn: 340849
Summary:
This greatly reduces the time to read 'compile_commands.json'.
For Chromium on my machine it's now 0.7 seconds vs 30 seconds before the
change.
Reviewers: sammccall, jfb
Reviewed By: sammccall
Subscribers: mgrang, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51314
llvm-svn: 340838
We add check for invalidation of iterators. The only operation we handle here
is the (copy) assignment.
Differential Revision: https://reviews.llvm.org/D32747
llvm-svn: 340805
Summary: When offloading to a device and using the powerpc64le version of the auxiliary triple, the _CALL_ELF macro is not set correctly to 2 resulting in the attempt to include a header that does not exist. This patch fixes this problem.
Reviewers: Hahnfeld, ABataev, caomhin
Reviewed By: Hahnfeld
Subscribers: guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51312
llvm-svn: 340772
Currently an address_space is stored in a qualifier. This makes any type
declared with an address_space attribute in the form
`__attribute__((address_space(1))) int 1;` be wrapped in an AttributedType.
This is for a later patch where if `address_space` is declared in a macro,
any diagnostics that would normally print the address space will instead dump
the macro name. This will require saving any macro information in the
AttributedType.
Differential Revision: https://reviews.llvm.org/D51229
llvm-svn: 340765
This also adds a second intrinsic name for the 16-bit mask versions.
These intrinsics match gcc and icc. They just aren't published in the Intel Intrinsics Guide so I only recently found they existed.
llvm-svn: 340719
When compiling CUDA or OpenMP device code Clang parses header files
that expect certain predefined macros from the host architecture. To
make this work the compiler passes the host triple via the -aux-triple
argument and (until now) pulls in all macros for that "auxiliary triple"
unconditionally.
However this results in defines like __SSE_MATH__ that will trigger
inline assembly making use of the "advertised" target features. See
the discussion of D47849 and PR38464 for a detailed explanation of
the encountered problems.
Instead of blacklisting "known bad" examples this patch starts adding
defines that are needed for certain headers like bits/wordsize.h and
bits/mathinline.h.
The disadvantage of this approach is that it decouples the definitions
from their target toolchain. However in my opinion it's more important
to keep definitions for one header close together. For one this will
include a clear documentation why these particular defines are needed.
Furthermore it simplifies maintenance because adding defines for a new
header or support for a new aux-triple only needs to touch one piece
of code.
Differential Revision: https://reviews.llvm.org/D50845
llvm-svn: 340681
As reported on http://lists.llvm.org/pipermail/cfe-dev/2018-August/058760.html,
this broke i386-freebsd11 due to its lack of atomic 64 bit primitives.
While that's not really this commit's fault, let's revert back to the old
behaviour until this can be fixed. This means generating cmpxchg8b etc for i386
and i486 which don't technically support those, but that's been the behaviour
for a long time, so a little longer probably doesn't hurt that much.
> Adjust MaxAtomicInlineWidth for i386/i486 targets.
>
> This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
> Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
> i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
> So in this patch MaxAtomicInlineWidth is reset as follows:
> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
>
> Differential Revision: https://reviews.llvm.org/D42154
llvm-svn: 340666
If all LLVM passes are disabled, we can't emit a summary because there
could be unnamed globals in the IR.
Differential Revision: https://reviews.llvm.org/D51198
llvm-svn: 340640
Summary:
The Bug was reported and fixed by Owen Pan. See the original bug report here: https://bugs.llvm.org/show_bug.cgi?id=38557
Patch by Owen Pan!
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: JonasToth, cfe-commits
Differential Revision: https://reviews.llvm.org/D50697
llvm-svn: 340624
Revert to the original behavior: only calculate real file path when
file is opened and avoid using InterndPath for real path calculation.
llvm-svn: 340602
Summary:
This partially rolls back the change in D48903:
89aa7f45a1 (diff-0025af005307891b5429b6a834823d5eR318)
`real_path` can be very expensive on real file systems, and calling it on each
opened file can slow down the compilation. This also slows down deserialized
ASTs for which real paths need to be recalculated for each input files again.
For clangd code completion latency (using preamble):
Before
{F7039629}
After
{F7039630}
Reviewers: ilya-biryukov, simark
Reviewed By: ilya-biryukov
Subscribers: kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51159
llvm-svn: 340598
Summary:
With this patch, the SMT backend is almost completely detached from the CSA.
Unfortunate consequence is that we missed the `ConditionTruthVal` from the CSA and had to use `Optional<bool>`.
The Z3 solver implementation is still in the same file as the `Z3ConstraintManager`, in `lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp` though, but except for that, the SMT API can be moved to anywhere in the codebase.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50772
llvm-svn: 340534
Summary:
By making SMTConstraintManager a template and passing the SMT constraint type and expr, we can further move code from the Z3ConstraintManager class to the generic SMT constraint Manager.
Now, each SMT specific constraint manager only needs to implement the method `bool canReasonAbout(SVal X) const`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50770
llvm-svn: 340533
Summary: There is no reason to have a base class for a context anymore as each SMT object carries a reference to the specific solver context.
Reviewers: NoQ, george.karpenkov, hiraditya
Reviewed By: hiraditya
Subscribers: hiraditya, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50768
llvm-svn: 340532
subtarget features for indirect calls and indirect branches.
This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.
I've continued to use subtarget features for now as they continue to
seem the best fit given the lack of other retpoline like constructs so
far.
The LLVM side is pretty simple. I'd like to eventually get rid of the
old feature, but not sure what backwards compatibility issues that will
cause.
This does remove the "implies" from requesting an external thunk. This
always seemed somewhat questionable and is now clearly not desirable --
you specify a thunk the same way no matter which set of things are
getting retpolines.
I really want to keep this nicely isolated from end users and just an
LLVM implementation detail, so I've moved the `-mretpoline` flag in
Clang to no longer rely on a specific subtarget feature by that name and
instead to be directly handled. In some ways this is simpler, but in
order to preserve existing behavior I've had to add some fallback code
so that users who relied on merely passing -mretpoline-external-thunk
continue to get the same behavior. We should eventually remove this
I suspect (we have never tested that it works!) but I've not done that
in this patch.
Differential Revision: https://reviews.llvm.org/D51150
llvm-svn: 340515
Tracking those can help to provide much better diagnostics in many cases.
In general, most of the visitor machinery should be refactored to allow
tracking the origin of arbitrary values.
rdar://36039765
Differential Revision: https://reviews.llvm.org/D51131
llvm-svn: 340475
Previously we only used target triple as provided which matches the
GCC behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.
Unfortunatelly, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should also check the normalized
triple when constructing paths for multiarch runtimes.
Differential Revision: https://reviews.llvm.org/D50547
llvm-svn: 340471
Summary:
`CXXNamedCastExpr` importing is already handled in the respective `VisitCXXNamedCastExpr` method.
So this code here can never be reached under normal circumstances and we might as well remove it.
This patch shouldn't change any observable behavior of the ASTImporter.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51110
llvm-svn: 340466
Summary:
It's already allowed to prematurely release a scoped lock, now we also
allow relocking it again, possibly even in another mode.
This is the second attempt, the first had been merged as r339456 and
reverted in r339558 because it caused a crash.
Reviewers: delesley, aaron.ballman
Reviewed By: delesley, aaron.ballman
Subscribers: hokein, cfe-commits
Differential Revision: https://reviews.llvm.org/D49885
llvm-svn: 340459
constants by default when there is no optimization.
GCC's option -fno-keep-static-consts can be used to not emit
unused static constants.
In Clang, since default behavior does not keep unused static constants,
-fkeep-static-consts can be used to emit these if required. This could be
useful for producing identification strings like SVN identifiers
inside the object file even though the string isn't used by the program.
Differential Revision: https://reviews.llvm.org/D40925
llvm-svn: 340439
This change fixes the problem in https://bugs.llvm.org/show_bug.cgi?id=38332
by allowing driver::Action::BackendJobClass to run with the analyzer.
Otherwise, such jobs will look up the non-existing compilation database
and then run without flags.
Also filter out the -Wa,* flags that could be passed to and ignored
by the clang compiler. Clang-tidy gives warnings about unused -Wa,* flags.
Differential Revision: http://reviews.llvm.org/D51002
llvm-svn: 340421
of the captured variable when determining whether the capture needs
special handing when the block is copied or disposed.
This fixes bugs in the handling of variables captured by a block that is
nested inside a lambda that captures the variables by reference.
rdar://problem/43540889
Differential Revision: https://reviews.llvm.org/D51025
llvm-svn: 340408
Summary:
`CallDecription` can only handle function for the time being. If we want to match c++ method, we can only use method name to match and can't improve the matching accuracy through the qualifiers.
This patch add the support for `QualifiedName` matching to improve the matching accuracy.
Reviewers: xazax.hun, NoQ, george.karpenkov, rnkovacs
Reviewed By: xazax.hun, NoQ, rnkovacs
Subscribers: Szelethus, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D48027
llvm-svn: 340407
Summary:
Currently there are several issues with the import of class template
specializations. (1) Different TUs may have class template specializations
with the same template arguments, but with different set of instantiated
MethodDecls and FieldDecls. In this patch we provide a fix to merge these
methods and fields. (2) Currently, we search the partial template
specializations in the set of simple specializations and we add partial
specializations as simple specializations. This is bad, this patch fixes it.
Reviewers: a_sidorin, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D50451
llvm-svn: 340402
Set __mips_fpr to 0 if o32 ABI is used with either -mfpxx
or none of -mfp32, -mfpxx, -mfp64 being specified.
Introduce additional checks:
-mfpxx is only to be used in conjunction with the o32 ABI.
report an error when incompatible options are provided.
Formerly no errors were raised when combining n32/n64 ABIs
with -mfp32 and -mfpxx.
There are other cases when __mips_fpr should be set to 0
that are not covered, ex. using o32 on a mips64 cpu
which is valid but not supported in the backend as of yet.
Differential Revision: https://reviews.llvm.org/D50557
llvm-svn: 340391
The command line option -fvisibility-inlines-hidden makes inlined method hidden, but it is expected not to affect the visibility of static local variables in the function.
However, Clang makes the static local variables in the function also hidden as reported in PR37595. This problem causes LLVM bootstarp failure on Fedora 28 if configured with -DBUILD_SHARED_LIBS=ON.
This patch makes the behavior of -fvisibility-inlines-hidden option to be consistent with that of gcc; the option does not change the visibility of the static local variables if the containing function does not associated with explicit visibility attribute and becomes hidden due to this option.
Differential Revision: https://reviews.llvm.org/D50968
llvm-svn: 340386
EmitX86BuiltinExpr() emits all args into Ops at the beginning, so don't do that
work again.
This changes behavior: If e.g. ++a was passed as an arg, we incremented a twice
previously. This change fixes that bug.
https://reviews.llvm.org/D50979
llvm-svn: 340348
If using a custom stack alignment, one is expected to make sure
that all callers provide such alignment, or realign the stack in
all entry points (and callbacks).
Despite this, the compiler can assume that the main function will
need realignment in these cases, since the startup routines calling
the main function most probably won't provide the custom alignment.
This matches what GCC does in similar cases; if compiling with
-mincoming-stack-boundary=X -mpreferred-stack-boundary=X, GCC normally
assumes such alignment on entry to a function, but specifically for
the main function still does realignment.
Differential Revision: https://reviews.llvm.org/D51026
llvm-svn: 340334
This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a
specific static or thread duration variable shouldn't have it's destructor
registered, and is the default in -fno-c++-static-destructors mode.
always_destroy is the opposite, and is the default in -fc++-static-destructors
mode.
A variable whose destructor is disabled (either because of
-fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of
the destructor, so we don't do any access checking or mark it referenced. We
also don't emit -Wexit-time-destructors for these variables.
rdar://21734598
Differential revision: https://reviews.llvm.org/D50994
llvm-svn: 340306
Summary:
r306722 introduced a new note called note_silence_unligned_allocation_unavailable
where I believe what was meant is note_silence_aligned_allocation_unavailable.
Reviewers: ahatanak
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51043
llvm-svn: 340288
Stephen Kelly