They're already defined in ia32intrin.h, and this would cause including Intrin.h
in 64-bit mode to fail because of conflicting types. Update ms-intrin.cpp to
also run in 64-bit mode to catch things like this.
llvm-svn: 203714
This updates CodeGenPGO to use the ProfileDataReader introduced to
llvm in r203703 and the new API for writing out the profile introduced
to compiler-rt in r203710.
llvm-svn: 203711
When a struct has bitfields overlapping with other members
(as required by the AAPCS), clang uses a packed struct to
represent this. If such a struct is large enough for clang to
pass it as a byval pointer (>64 bytes), we need to set the
alignment of the argument to match the original type.
llvm-svn: 203660
When enabled, always validate the system headers when loading a module.
The end result of this is that when these headers change, we will notice
and rebuild the module.
llvm-svn: 203630
Normalise the path separator character on non-windows platforms. Although this
would work on Windows as well (most newer versions of Windows support either '/'
or '\' as a path separator character), it could potentially cause problems with
full UNC paths. This change enables the use of the Windows SDK on Linux which
will not accept '\' as a path separator.
llvm-svn: 203614
PGO counters are 64-bit and branch weights are 32-bit. Scale them down
when necessary, instead of just taking the lower 32 bits.
<rdar://problem/16276448>
llvm-svn: 203592
Like the binary operator check of r201702, this actually checks the
condition of every if in a chain against every other condition, an
O(N^2) operation. In most cases N should be small enough to make this
practical, and checking all cases like this makes it much more likely
to catch a copy-paste error within the same series of branches.
Part of IdenticalExprChecker; patch by Daniel Fahlgren!
llvm-svn: 203585
Someone could write:
if (0) {
__c11_atomic_load(ptr, memory_order_release);
}
or the equivalent, which is perfectly valid, so we shouldn't outright reject
invalid orderings on purely static grounds.
rdar://problem/16242991
llvm-svn: 203564
Before:
auto aaaaaaaa = [](int i, // break
int j)
-> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
After:
auto aaaaaaaa = [](int i, // break
int j) -> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
llvm-svn: 203562
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
to absolute paths when building the includes file for the module. Without this,
the module build would fail, because the relative paths we were using are not
necessarily relative to a directory in our include path.
llvm-svn: 203528
Previously, we would always emit them with internal linkage,
but with hidden visibility when the function was hidden, which
is an illegal combination, which could lead LLVM to actually
emit them as strong hidden symbols with hilarious results.
rdar://16265084
llvm-svn: 203503
Summary:
'Expected' should only be modified if the operation fails.
This fixes PR18899.
Reviewers: chandlerc, rsmith, rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2922
llvm-svn: 203493
Summary:
Add loc() to the dynamic registry.
Other fixes:
- Fix the polymorphic variant value to accept an exact match, even if
there are other possible conversions.
- Fix specifiesTypeLoc() to not crash on an empty
NestedNameSpecifierLoc.
Reviewers: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2928
llvm-svn: 203467
if the type's declaration was previously instantiated in an unimported module.
(For an imported type definition, this already worked, because the source
location is set to the location of the definition, but for locally-instantiated
type definitions, it did not.)
llvm-svn: 203425
Clang might crash while reading the precompiled headers if
we don't initialize the AttrEnumOperandLoc properly.
This commit fixes the combination of string attribute
operand and enum operand. Besides, this commit also adds
several assertions to avoid unexpected operand kind.
llvm-svn: 203416
Padding does not seem to be useful currently, and it leads to bogus location if an error
points to the end of the file.
rdar://15836513
llvm-svn: 203370
r203364: what was use_iterator is now user_iterator, and there is
a use_iterator for directly iterating over the uses.
This also switches to use the range-based APIs where appropriate.
llvm-svn: 203365
This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage.
llvm-svn: 203362
This can possibly be refined later, but right now the experience
is so incomprehensible for a user to understand what is going on
this isn't a useful warning.
llvm-svn: 203336
This changes the iterators so that they are no longer implemented in terms of ranges (so it's a very partial revert of the existing rangification efforts).
llvm-svn: 203299
I had forgotten that the same reachability code is used by both -Wreturn-type
and -Wunreachable-code, so the heuristics applied to the latter were indirectly
impacting the former.
To address this, the reachability code is more refactored so that whiled
the logic at its core is shared, the intention of the clients are better
captured and segregated in helper APIs.
Fixes PR19074, and also some false positives reported offline to me
by Nick Lewycky.
llvm-svn: 203209
Add module dependencies to the dependency files created by -MD/-MMD/etc.
by attaching an ASTReaderListener that will call into the dependency
file generator when a module input file is seen in the serialized AST.
llvm-svn: 203208
the clang diagnostic has to report a column number one less than the correct
value in order for the IDE to move the cursor to the expected location. This
behavior is changed in VS2012 and VS2013 so that the IDE is now expecting the
column number to match the actual source location.
Before: source(line, column-1): type: message
After: source(line, column): type: message
This patch changes -fdiagnostics-format=msvc to match the new VS2012 and VS2013
when fmsc-version is 1700 or greater.
Differential Revision: http://llvm-reviews.chandlerc.com/D2949
llvm-svn: 203183
getTypeSize (which rounds up sizes) in order to issue diagnostics
when casting to mismatched vector sizes; instead of crashing in IRGen.
// rdar:// 16196902. Reviewed offline by John McCall.
llvm-svn: 203175
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.
The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.
llvm-svn: 203172
This patch fixes PR18964. In linkage computation, assertion fails when
an old invalid declaration's linkage mismatches with the current
decl's one.
llvm-svn: 203168
If a guard variable will be created for an entity at global scope,
then we cannot rely on the scope depth to disambiguate names for us.
Instead, mangle the entire variable into the guard to ensure it's uniqueness.
llvm-svn: 203151
Initializers and finalizers for static data members have the variable's
access-specifier, storage-class, type and CV-qualifiers mangled in.
llvm-svn: 203145
Summary:
Added an inserter for ArrayRef<SourceRange>, as it is already needed in at least
two places (static analyzer and clang-tidy).
Reviewers: jordan_rose
CC: cfe-commits, gribozavr
Differential Revision: http://llvm-reviews.chandlerc.com/D2984
llvm-svn: 203117
I have mixed feelings about this one. It's used all over the codebase,
and is analogous to the current heuristic for ordinary C string literals.
This requires some ad hoc pattern matching of the AST. While the
test case mirrors what we see std::string in libc++, it's not really
testing the libc++ headers.
llvm-svn: 203091
In addition, for all functions, use the name from the llvm::Function to
identify the function in the profile data. Compute that "function name",
including the file name for local functions, once when assigning the PGO
counters and store it in the CodeGenPGO class.
Move the code to add InlineHint and Cold attributes out of StartFunction(),
because the "function name" string isn't available at that point.
llvm-svn: 203075
For C++ functions, we will continue to use the mangled name to identify
functions in the PGO profile data, but this name is confusing for things like
Objective-C methods. For functions with local linkage, we're also going to
include the file name to help distinguish those functions, so this changes to
use more generic variable names.
No functional changes.
llvm-svn: 203074
Move the PGO.assignRegionCounters() call out of StartFunction, because that
function is called from many places where it does not make sense to do PGO
instrumentation (e.g., compiler-generated helper functions). Change several
functions to take a StringRef argument for the unique name associated with
a function, so that the name can be set differently for things like Objective-C
methods and block literals.
llvm-svn: 203073
I hit this while debugging another issue where my sources were in an
inconsistent state, so I don't have a testcase. Regardless, this check is
simpler and more direct than checking if the option is enabled.
llvm-svn: 203072
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
llvm-svn: 203063
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203051
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203036
Previously we only pruned dead returns preceded by a call to a
'noreturn' function. After looking at the results of the LLVM codebase,
there are many others that should be pruned as well.
llvm-svn: 203029
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
llvm-svn: 203012
Use a scheme inspired by the Itanium ABI to properly implement the
mangling of lambdas.
N.B. The incredibly astute observer will notice that we do not generate
external names that are identical, or even compatible with, MSVC.
This is fine because they don't generate names that they can use across
translation units. Technically, we can generate any name we'd like so
long as that name wouldn't conflict with any other and would be stable
across translation units.
This fixes PR15512.
llvm-svn: 202962
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
llvm-svn: 202948
Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant. Sometimes those represent real bugs,
but often they do not. This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself. There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.
llvm-svn: 202912
Summary:
Our usual definition of max_align_t wouldn't match up with MSVC if it
was used in a template argument.
Reviewers: chandlerc, rsmith, rnk
Reviewed By: chandlerc
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2924
llvm-svn: 202911
Use llvm::sys::fs::make_absolute to get an absolute path before
matching. Also, allow "." directories to enable testing. ".." is still
not supported, and will require crossing file system boundaries to
implement correctly.
llvm-svn: 202903
This fails an "isa<> used with null pointer" assert during a clang-cl
self-host on Windows. This was caused by r202769, and I'm currently
reducing a test case.
Reviewers: dblaikie
Differential Revision: http://llvm-reviews.chandlerc.com/D2944
llvm-svn: 202888
line arguments and directories tree. The old toolchain selection heuristics
worked incorrectly when user has a reduced MIPS toolchain supports
the O32 ABI only.
Patch reviewed by Jonathan Roelofs, David Majnemer.
llvm-svn: 202873
if an ivar offset load is invariant iff inside an instance method
and ivar belongs to instance method's class and one of its super class.
// rdar://16095748
llvm-svn: 202872
and one for PCLMUL support. The current immintrin.h header only includes
wmmintrin.h if AES support is enabled. It should include it if either AES or
PCLMUL is enabled (GCC's version of immintrin.h does this).
Patch by John Baldwin!
llvm-svn: 202871
anonymous structs to the same Decl in the
ASTImporter, ensure that both are filled in
from their external sources (if present).
Otherwise two different structs may be
identified erroneously.
llvm-svn: 202869
Richard Smith