| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 220032
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
tests showing what we get wrong.
llvm-svn: 220009
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
cross-compiler by default
llvm-svn: 219989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reverted in r218058 because they triggered a rejects-valid bug in MSVC.
Original commit message from r217995:
Instantiate exception specifications when instantiating function types (other
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
llvm-svn: 219977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A second instance of attributed types escaped the previous change, identified
thanks to Richard Smith! When deducing the void case, we would also assume that
the type would not be attributed. Furthermore, properly handle multiple
attributes being applied to a single TypeLoc.
Properly handle this case and future-proof a bit by ignoring parenthesis
further. The test cases do use the additional parenthesis to ensure that this
case remains properly handled.
Addresses post-commit review comments from Richard Smith to SVN r219851.
llvm-svn: 219974
|
| |
|
|
| |
llvm-svn: 219969
|
| |
|
|
| |
llvm-svn: 219965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AddressSanitizer can find intra-object-overflow bugs
Summary:
The general approach is to add extra paddings after every field
in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings
(CodeGen/CGClass.cpp).
Everything is done under the flag -fsanitize-address-field-padding.
The blacklist file (-fsanitize-blacklist) allows to avoid the transformation
for given classes or source files.
See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding
Reviewers: samsonov, rnk, rsmith
Reviewed By: rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D5687
llvm-svn: 219961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They cannot be written to, so marking them const makes sense and may improve
optimisation.
As a side-effect, SectionInfos has to be moved from Sema to ASTContext.
It also fixes this problem, that occurs when compiling ATL:
warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes
The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.
Differential Revision: http://reviews.llvm.org/D5812
llvm-svn: 219960
|
| |
|
|
|
|
| |
unevaluated contexts. Fixes PR18571.
llvm-svn: 219954
|
| |
|
|
| |
llvm-svn: 219952
|
| |
|
|
|
|
| |
constant value in this case as well.
llvm-svn: 219943
|
| |
|
|
| |
llvm-svn: 219933
|
| |
|
|
|
|
| |
The test is a C++ semantic analysis test, move it to SemaCXX from Sema. NFC.
llvm-svn: 219932
|
| |
|
|
| |
llvm-svn: 219929
|
| |
|
|
|
|
| |
The ensures there is an explicit address space id in the output.
llvm-svn: 219928
|
| |
|
|
| |
llvm-svn: 219901
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference-ness, etc) for non-type template parameters
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
|
| |
|
|
|
|
|
| |
Fix for clang crash when instantiating a template with qualified lookup for members in non-class types.
Differential Revision: http://reviews.llvm.org/D5769
llvm-svn: 219897
|
| |
|
|
|
|
|
|
|
|
| |
Separate out the non-nullable parameters from the nullable ones
(currently only the template template parameter) and demonstrate that
cv-qualifiers aren't preserved for non-null parameters (but are
preserved for null parameters) by adding 'const' to an int* non-type
template parameter.
llvm-svn: 219883
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.
Even if the definition was already emitted, it would never mark the
alias as thread_local.
This fixes PR21288.
llvm-svn: 219859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing a type deduction from the return type, the FunctionDecl may be
attributed with a calling convention. In such a case, the retrieved type
location may be an AttributedTypeLoc. Performing a castAs<FunctionProtoTypeLoc>
on such a type loc would result in an assertion as they are not derived types.
Ensure that we correctly handle the attributed type location by looking through
it to the modified type loc.
Fixes an assertion triggered in C++14 mode.
llvm-svn: 219851
|
| |
|
|
|
|
| |
Remove the use of an unnecessary function. NFC.
llvm-svn: 219850
|
| |
|
|
|
|
| |
PPC64/NetBSD.
llvm-svn: 219839
|
| |
|
|
|
|
| |
struct/union fields. This fixes PR20930.
llvm-svn: 219807
|
| |
|
|
|
|
|
|
| |
In particular, if you have two identical templates in different TUs in
anonymous namespaces, we would use the same global_ctors comdat key for
both. As a result, only one would be run.
llvm-svn: 219806
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The size of the ID field in CommandInfo was narrow, leading to potential
wrap-around of command IDs, causing misinterpretation later on.
The patch does the following:
- It extends the ID bitfield from 8 to 20 bits.
- It provides a DRY definition of the number of bits for the field to
avoid using literal numbers in different files.
- It introduces a new assertion that checks for the wrap-around.
- It adds the testcase from PR21254.
llvm-svn: 219802
|
| |
|
|
| |
llvm-svn: 219797
|
| |
|
|
|
|
|
|
|
|
| |
Unions are initialized with the default initialization of their first
named member. If that member is not zero initialized, then we should
prefer that member's type. Otherwise, we might try to make an otherwise
unsuitable type (like an array) which we cannot easily initialize with a
pointer to member.
llvm-svn: 219781
|
| |
|
|
|
|
|
| |
We assumed the last argument of the copy constructor was the this
pointer. However, this is not the case under the MS ABI.
llvm-svn: 219775
|
| |
|
|
|
|
|
|
|
| |
Split logic to separate checking function
Refine the macro checking
Catch nullptr->bool conversions
Add some explanatory comments
llvm-svn: 219774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AddressSanitizer currently doesn't support this configuration, and binaries
built with it will just get into an infinite loop during startup.
Test Plan: Includes an automated test.
Reviewers: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5764
llvm-svn: 219744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
canonical declaration for line/file information.
When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).
llvm-svn: 219736
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.
So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.
llvm-svn: 219735
|
| |
|
|
|
|
|
|
|
| |
Specifically, avoid typo-correcting the variable name into a type before
typo-correcting the actual type name in the declaration. Doing so
results in a very unpleasant cascade of errors, with the typo correction
of the actual type name being buried in the middle.
llvm-svn: 219732
|
| |
|
|
|
|
|
|
|
|
|
| |
Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.
There's no actual ABI change here, just to reassure people.
llvm-svn: 219720
|
| |
|
|
|
|
|
| |
implicit casts. Reviewed by Reid Kleckner.
rdar://18405357
llvm-svn: 219712
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Mangling for blocks defined within blocks in an ObjectiveC context were also
broken by SVN r219393. Because the code in mangleName assumed that the code was
either C or C++, we would trigger assertions when trying to mangle the inner
blocks in an ObjectiveC context.
Add a test and use the ObjectiveC specific mangling when dealing with an
ObjectiveC method declaration.
llvm-svn: 219697
|