Logical short-circuit operators now act like other branch conditions.
If the symbolic value of the left-hand side is not known to be true or false
(based on the previous execution path), the "Assuming" event piece is added
in order to explain that the analyzer is adding a new assumption.
Additionally, when the assumption is made against the right-hand side of
the logical operator (i.e. when the operator itself acts as a condition
in another CFG terminator), the "Assuming..." piece is written out for the
right-hand side of the operator rather than for the whole operator.
This allows expression-specific diagnostic message text to be constructed.
Differential Revision: https://reviews.llvm.org/D25092
llvm-svn: 283302
In the analyzer's path-sensitive reports, when a report goes through a branch
and the branch condition cannot be decided to be definitely true or false
(based on the previous execution path), an event piece is added that tells the
user that a new assumption is added upon the symbolic value of the branch
condition. For example, "Assuming 'a' is equal to 3".
The text of the assumption is hand-crafted in various manners depending on
the AST expression. If the AST expression is too complex and the text of
the assumption fails to be constructed, the event piece is omitted.
This causes loss of information and misunderstanding of the report.
Do not omit the event piece even if the expression is too complex;
add a piece with a generic text instead.
Differential Revision: https://reviews.llvm.org/D23300
llvm-svn: 283301
Do not merge sections if generating a relocatable object. It makes
the code simpler because we do not need to update relocations addends
to reflect changes introduced by merging. Instead of that we write
such "merge" sections into separate OutputSections and keep SHF_MERGE
/ SHF_STRINGS flags and sh_entsize value to be able to perform merging
later during a final linking.
Differential Revision: http://reviews.llvm.org/D25066
llvm-svn: 283300
Reapply 282061.
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
The logic is complicated a bit by the fact that the sanitizers always pick the
oldest version of the symbol available in glibc, which creates discrepancies
between old platforms which contain several versions od the sem_init symbol, and
newer platforms which contain only one.
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 283299
Summary:
This adds the AVR machine code backend (`AVRAsmBackend.cpp`). This will
allow us to generate machine code from assembled AVR instructions.
Reviewers: arsenm, kparzysz
Subscribers: modocache, japaric, wdng, beanz, mgorny
Differential Revision: https://reviews.llvm.org/D25029
llvm-svn: 283297
This should allow users of the library to get a range to iterate through
all the subcommands that are registered to the global parser. This
allows users to define subcommands in libraries that self-register to
have dispatch done at a different stage (like main). It allows for
writing code like the following:
for (auto *S : cl::getRegisteredSubcommands()) {
if (*S) {
// Dispatch on S->getName().
}
}
This change also contains tests that show this usage pattern.
Reviewers: zturner, dblaikie, echristo
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24489
llvm-svn: 283296
which specifies a file path and UUID but not an architecture, open
the file at that path and try every one of the architectures in the
file to see if there is a UUID match. Currently we'll pick the
first slice of a multi-architecture file and return that as the
match, and when the UUID doesn't match because it's the wrong
architecture, we'll end up ignoring the file.
<rdar://problem/28487804>
llvm-svn: 283295
This reverts commit 062ace9764953e9769142c1099281a345f9b6bdc.
Issue with loop info and block removal revealed by polly.
I have a fix for this issue already in another patch, I'll re-roll this
together with that fix, and a test case.
llvm-svn: 283292
The tail duplication pass uses an assumed layout when making duplication
decisions. This is fine, but passes up duplication opportunities that
may arise when blocks are outlined. Because we want the updated CFG to
affect subsequent placement decisions, this change must occur during
placement.
In order to achieve this goal, TailDuplicationPass is split into a
utility class, TailDuplicator, and the pass itself. The pass delegates
nearly everything to the TailDuplicator object, except for looping over
the blocks in a function. This allows the same code to be used for tail
duplication in both places.
This change, in concert with outlining optional branches, allows
triangle shaped code to perform much better, esepecially when the
taken/untaken branches are correlated, as it creates a second spine when
the tests are small enough.
Issue from previous rollback fixed, and a new test was added for that
case as well.
Differential revision: https://reviews.llvm.org/D18226
llvm-svn: 283274
Summary:
This prevents clang from emitting 'invoke's and catch statements.
Things previously mostly worked thanks to TryToMarkNoThrow() in
CodeGenFunction. But this is not a proper IPO, and it doesn't properly
handle cases like mutual recursion.
Fixes bug 30593.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25166
llvm-svn: 283272
Summary:
This will let us (in a separate patch) allocate deferred diagnostics in
the ASTContext's PartialDiagnostic arena.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25260
llvm-svn: 283271
Summary:
These are analog to the existing LLVMConstExactSDiv and LLVMBuildExactSDiv
functions.
Reviewers: deadalnix, majnemer
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D25259
llvm-svn: 283269
Summary:
Attempting to fix PR30384.
Take the same approach as in compiler_rt and add a simplified version of __get_cpuid_max.
Including cpuid.h is no longer needed.
Reviewers: echristo, joerg
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24597
llvm-svn: 283265
Summary: We need x86-64-specific builtins if we want to implement some of the MS intrinsics - winnt.h contains definitions of some functions for i386, but not for x86-64 (for example _InterlockedOr64), which means that we cannot treat them as builtins for both i386 and x86-64, because then we have definitions of builtin functions in winnt.h on i386.
Reviewers: thakis, majnemer, hans, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24598
llvm-svn: 283264
The package that strong name signs the 3rd party references
spams a ton of output to the log, making the build really ugly.
Make this quiet.
llvm-svn: 283261
Summary: There's a macro scheme already being used for __has_feature etc. Use it for __has_include too, which makes MSVC happy (it doesn't support __has_include yet, and unguarded use explodes horribly).
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25251
llvm-svn: 283260
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arch that this supports is x86 64 bit
This is because I have only written a register context for that arch.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, amccarth, lldb-commits, modocache
Differential Revision: https://reviews.llvm.org/D25196
llvm-svn: 283259
We could hook up /GL as an alias for -flto, but that might be
confusing, as clang-cl in that mode would not be drop-in compatible
with cl.exe /GL, as it requires the linker to be lld.
Exposing -flto seems like a less confusing way to expose this
functionality.
llvm-svn: 283255
Artem Dergachev