| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
llvm-svn: 220175
|
| |
|
|
| |
llvm-svn: 220170
|
| |
|
|
|
|
|
|
|
|
| |
after padding"
This commit caused two tests in LNT to regress. I'm able to reproduce on
any platform and will send reproduction steps to the original commit
log. This should restore the LNT bots that have been failing.
llvm-svn: 220169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a NaN-test prior to the call to the library function.
This should automatically make fastmath (including just non-NaNs) able to avoid
the expensive libcalls and also open the door to more advanced folding in LLVM
based on the rules for complex math.
Two important notes to remember: first is that this isn't yet a proper
limited range mode, it's still just improving the unlimited range mode.
Also, it isn't really perfecet w.r.t. what an unlimited range mode
should be doing because it isn't quite handling the flags produced by
all the operations in the way desirable for that mode, but then neither
is compiler-rt's libcall. When the compiler-rt libcall is improved to
carefully manage flags, the code emitted here should be improved
correspondingly. And it is still a long-term desirable thing to add
a limited range mode to Clang that would be able to use direct math
without library calls here.
Special thanks to Steve Canon for the careful review on this patch and
teaching me about these issues. =D
Differential Revision: http://reviews.llvm.org/D5756
llvm-svn: 220167
|
| |
|
|
| |
llvm-svn: 220166
|
| |
|
|
|
|
|
|
|
|
|
| |
allocate a bunch of any pointer type.
This suppresses a common false positive when analyzing libc++.
Along the way, introduce some tests to show this checker actually
works with C++ static_cast<>.
llvm-svn: 220160
|
| |
|
|
| |
llvm-svn: 220158
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before, ConstStructBuilder::AppendBytes would check packed constraints
prior to padding being added before the field's offset. However, adding
this padding might force our struct to be packed. Because we wouldn't
check *after* adding padding, ConstStructBuilder would be in an
inconsistent state leading to a crash.
This fixes PR21300.
llvm-svn: 220153
|
| |
|
|
|
|
|
|
| |
clang tests were breaking, at least when compiling clang only, from an
installed llvm. Make the lit.cfg script deal with the case when we don't
have a host_triple available.
llvm-svn: 220148
|
| |
|
|
| |
llvm-svn: 220140
|
| |
|
|
|
|
|
|
|
| |
position at the beginning of the file after the preamble.
Otherwise we will not hit the code-completion point.
llvm-svn: 220136
|
| |
|
|
| |
llvm-svn: 220135
|
| |
|
|
|
|
| |
Patch by Stephen Crane!
llvm-svn: 220122
|
| |
|
|
|
|
| |
We will fail if it's not set, even if we don't substitute.
llvm-svn: 220114
|
| |
|
|
| |
llvm-svn: 220112
|
| |
|
|
|
|
| |
appease msc17.
llvm-svn: 220111
|
| |
|
|
| |
llvm-svn: 220098
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:
1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.
2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.
3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().
After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).
llvm-svn: 220097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Correctly compute the non-virtual size of a class.
Test Plan: Build SPEC 2016 with -fsanitize-address-field-padding
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5848
llvm-svn: 220089
|
| |
|
|
|
|
|
| |
template specialization type dependent, even if it has no dependent template
arguments. I've filed a corresponding bug against the C++ standard.
llvm-svn: 220088
|
| |
|
|
| |
llvm-svn: 220087
|
| |
|
|
| |
llvm-svn: 220086
|
| |
|
|
|
|
|
| |
of a member function of a class template that is defined outside the template.
This substitution can actually fail in some weird cases.
llvm-svn: 220085
|
| |
|
|
|
|
| |
The test was running with -xc++. Seems it wants to be a C++ file.
llvm-svn: 220069
|
| |
|
|
|
|
| |
Code review feedback from Richard Smith on r219900.
llvm-svn: 220060
|
| |
|
|
|
|
|
| |
Hoist the IgnoreParens so that we ignore it around attributes as well in order
to future-proof the code. Addresses Richard's comments for SVN r219974.
llvm-svn: 220053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
without dash (PR21094)
Clang would previously not get into C++ mode when invoked as 'clang++3.6'
(though clang++-3.6 would work).
I found the previous loop logic in this function confusing; hopefully this
makes it a little clearer.
Differential Revision: http://reviews.llvm.org/D5833
llvm-svn: 220052
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
auto SomeFunction(
A aaaaaaaaaaaaaaaaaaaaa) const -> decltype(f(aaaaaaaaaaaaaaaaaaaaa)) {}
After:
auto SomeFunction(A aaaaaaaaaaaaaaaaaaaaa) const
-> decltype(f(aaaaaaaaaaaaaaaaaaaaa)) {}
llvm-svn: 220043
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
public void doSooooooooooooooooooooooooooomething() throws
LooooooooooooooooooooooooooooongException {}
After:
public void doSooooooooooooooooooooooooooomething()
throws LooooooooooooooooooooooooooooongException {}
llvm-svn: 220041
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r218053). These were"
It broke some builders. I guess it'd be reproducible with --vg.
Failing Tests (3):
Clang :: CXX/except/except.spec/p1.cpp
Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp
Clang :: SemaTemplate/instantiate-exception-spec.cpp
llvm-svn: 220038
|
| |
|
|
|
|
| |
clang/test/CodeGen/sanitize-address-field-padding.cpp, for now. It's incompatible to ms mangling.
llvm-svn: 220037
|
| |
|
|
| |
llvm-svn: 220034
|
| |
|
|
|
|
|
|
|
|
|
| |
RecordType->getDecl() which maps to TagType::getDecl() is not a simple
accessor but a loop on redecls in getInterestingTagDecl.
isStructureOrClassType() was calling getDecl() three times performing
three times the work actually required. It is optimized by calling
RT->getDecl() once and reusing the result three times.
llvm-svn: 220033
|
| |
|
|
| |
llvm-svn: 220032
|
| |
|
|
|
|
| |
Patch by Evgeny Astigeevich!
llvm-svn: 220031
|
| |
|
|
| |
llvm-svn: 220030
|
| |
|
|
| |
llvm-svn: 220029
|
| |
|
|
|
|
|
| |
non-dependent types, in CXXScalarValueInitExprs and in the
nested-name-specifier or template arguments of a DeclRefExpr in particular.
llvm-svn: 220028
|
| |
|
|
| |
llvm-svn: 220023
|
| |
|
|
|
|
| |
loading multiple module map files from the same directory.
llvm-svn: 220020
|
| |
|
|
| |
llvm-svn: 220014
|
| |
|
|
|
|
| |
tests showing what we get wrong.
llvm-svn: 220009
|
| |
|
|
|
|
|
| |
It exists to handle the case where base subobjects are character arrays.
This never happens.
llvm-svn: 220006
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 220005
|
| |
|
|
| |
llvm-svn: 220002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
|
| |
|
|
| |
llvm-svn: 219994
|
| |
|
|
| |
llvm-svn: 219993
|
| |
|
|
|
|
| |
cross-compiler by default
llvm-svn: 219989
|