Clang-side cross-DSO CFI.
* Adds a command line flag -f[no-]sanitize-cfi-cross-dso.
* Links a runtime library when enabled.
* Emits __cfi_slowpath calls is bitset test fails.
* Emits extra hash-based bitsets for external CFI checks.
* Sets a module flag to enable __cfi_check generation during LTO.
This mode does not yet support diagnostics.
llvm-svn: 255694
This updates clang to use bundle operands to associate an invoke with
the funclet which it is contained within.
Depends on D15517.
Differential Revision: http://reviews.llvm.org/D15518
llvm-svn: 255675
Clang doesn’t support a use of “this” pointer inside inline asm.
When I tried to compile a class or a struct (see example) with an inline asm that contains "this" pointer.
Clang returns with an error.
This patch fixes that.
error: expected unqualified-id
For example:
'''
struct A {
void f() {
__asm mov eax, this
// error: expected unqualified-id
}
};
'''
Differential Revision: http://reviews.llvm.org/D15115
llvm-svn: 255645
error: 'warning' diagnostics expected but not seen:
File clang/test/Analysis/padding_c.c Line 194 (directive at clang/test/Analysis/padding_c.c:193): Excessive padding in 'struct DefaultAttrAlign'
1 error generated.
llvm-svn: 255636
Summary:
The current default is to create the preamble on the first reparse, aka
second parse. This is useful for clients that do not want to block when
opening a file because serializing the preamble takes a bit of time.
However, this makes the reparse much more expensive and that may be on the
critical path as it's the first interaction a user has with the source code.
YouCompleteMe currently optimizes for the first code interaction by parsing
the file twice when loaded. That's just unnecessarily slow and this flag
helps to avoid that.
Reviewers: doug.gregor, klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15490
llvm-svn: 255635
(test case update)
Profile symbols have long prefixes which waste space and creating pressure for linker.
This patch shortens the prefixes to minimal length without losing verbosity.
Differential Revision: http://reviews.llvm.org/D15503
llvm-svn: 255576
Given the following code:
int *_Nullable ptr;
int *_Nonnull nn = ptr;
...In C, clang will warn you about `nn = ptr`, because you're assigning
a nonnull pointer to a nullable pointer. In C++, clang issues no such
warning. This patch helps ensure that clang doesn't ever miss an
opportunity to complain about C++ code.
N.B. Though this patch has a differential revision link, the actual
review took place over email.
Differential Revision: http://reviews.llvm.org/D14938
llvm-svn: 255556
The intent of this checker is to generate a report for any class / structure
that could reduce its padding by reordering the fields. This results in a very
noisy checker. To reduce the noise, this checker will currently only warn when
the number of bytes over "optimal" is more than 24. This value is configurable
with -analyzer-config performance.Padding:AllowedPad=N. Small values of
AllowedPad have the potential to generate hundreds of reports, and gigabytes
of HTML reports.
The checker searches for padding violations in two main ways. First, it goes
record by record. A report is generated if the fields could be reordered in a
way that reduces the padding by more than AllowedPad bytes. Second, the
checker will generate a report if an array will cause more than AllowedPad
padding bytes to be generated.
The record checker currently skips many ABI specific cases. Classes with base
classes are skipped because base class tail padding is ABI specific. Bitfields
are just plain hard, and duplicating that code seems like a bad idea. VLAs are
both uncommon and non-trivial to fix.
The array checker isn't very thorough right now. It only checks to see if the
element type's fields could be reordered, and it doesn't recursively check to
see if any of the fields' fields could be reordered. At some point in the
future, it would be nice if "arrays" could also look at array new usages and
malloc patterns that appear to be creating arrays.
llvm-svn: 255545
The issue seems to be that .ll file may either use number of register
value or alias %numUsedRegs, so the check needs to cover both cases.
This will hopefully fix the last regression introduced by r255515.
llvm-svn: 255539
The documentation suggests /Wall should really turn on -Wextra and any
other warnings that are not enabled by default. That would correspond
to Clang's -Weverything, but is probably not what users want.
llvm-svn: 255524
We'd like to remove support for terminatepad from LLVM. To do this, we
need to move Clang off of it first. The intent behind terminatepad was
to carefully model exception specifications for the MSVC personality.
However, we don't support exception specifications for the MSVC
personality and neither does MSVC. Instead, MSVC supports
all-or-nothing exception specifications. We can model this limited
usage using cleanuppads which call std::terminate.
Differential Revision: http://reviews.llvm.org/D15478
llvm-svn: 255521
This patch enables soft float support for ppc32 architecture and fixes
the ABI for variadic functions. This is the first in a set of patches
for soft float support in LLVM.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D13351
llvm-svn: 255515
- Removed support for hexagonv3 and earlier.
- Added handling of hexagonv55 and hexagonv60.
- Added handling of target features (hvx, hvx-double).
- Updated paths to reflect current directory layout.
llvm-svn: 255502
Revision 251405 added AlwaysBreak to support Google's JavaScript style. This
changeset complete existing AlignsAfterOpenBracket tests to exercise
AlwaysBreak for C++.
I thought this would be worthwhile. With this option we can support request
from http://lists.llvm.org/pipermail/cfe-dev/2015-May/042942.html, that had
been requested a few times. This also partially solve related Bug 23422 and is
probably sufficient for most people.
AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
BinPackArguments = false;
BinPackParameters = false;
With these setting we obtain this formatting:
void fooWithAVeryLongParamList(
int firstParameter,
int secondParameter
int lastParameter)
{
object.alsoThisDoenstFitSoIBreakImmidiatly(
firstParameter,
secondParameter,
lastParameter);
}
Patch by Jean-Philippe Dufraigne, thank you.
llvm-svn: 255486
This sets the maximum entry count among all functions in the program to the
module using module flags. This allows the optimizer to use this information.
Differential Revision: http://reviews.llvm.org/D15163
llvm-svn: 255397
have a nested name specifier. Strictly speaking, forward declarations of class
template partial specializations are not permitted at all, but that seems like
an obvious wording defect, and if we allow them without a nested name specifier
we should also allow them with a nested name specifier.
llvm-svn: 255383
Evgeniy Stepanov