This adds coverage for Unicode code points which are encoded with
non-zero values in the upper half of the wchar_t.
No functionality change.
llvm-svn: 205251
This removes a diagnostic that is no longer required (the semantic engine now properly handles attribute syntax so __declspec and __attribute__ spellings no longer get mismatched). This caused several testcases to need updating for a slightly different wording.
llvm-svn: 205234
Summary:
The definition of a type later in a translation unit may change it's
type from {}* to (%struct.foo*)*. Earlier function definitions may use
the former while more recent definitions might use the later. This is
fine until they interact with one another (like one calling the other).
In these cases, a bitcast is needed because the inalloca must match the
function call but the store to the lvalue which initializes the argument
slot has to match the rvalue's type.
This technique is along the same lines with what the other,
non-inalloca, codepaths perform.
This fixes PR19287.
Reviewers: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3224
llvm-svn: 205217
This adds support for the various NEON intrinsics used by
aarch64-neon-intrinsics.c (originally written for AArch64) and enables the
test.
My implementations are designed to be semantically correct, the actual code
quality looks like its a wash between the two backends, and is frequently
different (hence the large number of CHECK changes).
llvm-svn: 205210
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
contents than the header file by the same name under the system header
search root. Surprisingly, this is required to get the test to pass on
some systems.
So, it turns out that there exist filesystems in the world which unique
the inode of all files based on their contents. This results in two
files with the same contents at different paths suddenly having the same
inode. This doesn't actually cause any problems in practice as the
contents are the same, and the path used to access the files are the
same. However, it can cause tests like this one to be more brittle
because the file manager ends up de-duplicating the file entries by
inode. We don't have any other really easy ways to observe the behavior
shift because the whole point is that the #include written in the source
code doesn't contain the information -- instead it is contained in the
header map.
If folks have other solutions they would prefer, I'm more than happy to
work on them, but this seems a reasonable way to ensure that the test in
question exercises the code it wants to exercise.
llvm-svn: 205149
Really, all tests outside of the Driver tree should use %clang_cc1, but
these are new and easy to fix, and many of them use buitlin headers
which don't work as well without using %clang_cc1.
llvm-svn: 205147
At least on REL6 (Linux/glibc 2.12), the proper symbol for generating gprof
data is _mcount, not mcount. Prior to this change, compiling with -pg would
generate linking errors (because of unresolved references to mcount), after
this change -pg seems at least minimally functional.
llvm-svn: 205144
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
llvm-svn: 205099
Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead. For example:
if ((0)) { dead }
When this sigil is found, do not emit a dead code warning. When the
analysis sees:
if (0)
it suggests inserting '()' as a Fix-It.
llvm-svn: 205069
The test was failing because clang-cl changes the default triple
to target MSVC-style Win32. This is kind of wonky, but hasn't been
a problem until we started warning:
warning: unknown platform, assuming -mfloat-abi=soft
Some of the tests in cl-options.c were running with -Werror, causing them
to fail.
Fixing this by FileCheck-ifying those tests instead of using -Werror.
llvm-svn: 205049
-Wselector-type-mismatch default again. After
internal discussions, we think that in most cases
it has helped our developers find hard to detect
undefined behaviors. We are going to provide a syntax
(and fix-it) to suppress the warning in remaining of
false positive cases.
llvm-svn: 205024
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
llvm-svn: 204935
When parsing MS inline assembly, we note that fpsw is an implicit def of
most x87 FP operations, and add it to the clobber list. However, we
don't recognize fpsw as a gcc register name, and we assert. Clang
always adds an fpsr clobber, which means the same thing to LLVM, so we
can just use that.
This test case was broken by my LLVM change r196939.
Reviewers: echristo
Differential Revision: http://llvm-reviews.chandlerc.com/D2993
llvm-svn: 204878
instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.
llvm-svn: 204874
This commit fixes a cast instruction assertion failure
due to the incompatible type cast. This will only happen when
the target requires atomic libcalls.
llvm-svn: 204834
Add M_ZERO awareness to malloc() static analysis in Clang for FreeBSD,
NetBSD, and OpenBSD in a similar fashion to O_CREAT for open(2).
These systems have a three-argument malloc() in the kernel where the
third argument contains flags; the M_ZERO flag will zero-initialize the
allocated buffer.
This should reduce the number of false positives when running static
analysis on BSD kernels.
Additionally, add kmalloc() (Linux kernel malloc()) and treat __GFP_ZERO
like M_ZERO on Linux.
Future work involves a better method of checking for named flags without
hardcoding values.
Patch by Conrad Meyer, with minor modifications by me.
llvm-svn: 204832
Hopefully addresses r204539.
Make clang/test/lit.cfg pre-scan the RUN line looking for tool names,
and substitute fully qualified path names pointing to the build
directory. This ensures we're testing the just-built tools.
llvm-svn: 204831
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
Summary:
This allows them to be used without -cc1 the same way as -I and -isystem.
Renamed the options to --system-header-prefix=/--no-system-header-prefix to avoid interference with -isystem and make the intent of the option cleaner.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3185
llvm-svn: 204775
Conceptually one of these loops is just a while-loop, but the actual code-gen
is more complicated. We don't instrument all the different control flow edges
to get accurate counts for each conditional branch, nor do I think it makes
sense to do so. Instead, make the simplifying assumption that the loop behaves
like a while-loop. Use the same branch weights for the first check for an
empty collection as would be used for the back-edge of a while loop, and use
that same weighting for the innermost loop, ignoring the possibility that there
may be some extra code to go fetch more elements.
llvm-svn: 204767
In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.
Patch by Zinovy Nis!
Differential Revision: http://llvm-reviews.chandlerc.com/D3114
llvm-svn: 204742
A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.
With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)
Thanks to Ted for spotting a few mistakes in private review.
<rdar://problem/16333368>
llvm-svn: 204730
an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.
llvm-svn: 204694
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
As of cl.exe version 18, the special layout rules for structs with
alignment 16 or greater has been dropped. This patch drops the behavior
from clang. This patch also updates the lit tests to reflect the
change.
llvm-svn: 204674
Use two check-prefix patterns per FileCheck invocation for these tests,
this cleanly removes redundant CHECK directives.
Thanks to Richard Smith for the idea!
llvm-svn: 204587
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
/Gy is equivalent to -ffunction-sections.
/Gy- is equivalent to -fno-function-sections.
Currently, LLVM doesn't do anything interesting with -ffunction-sections
under WinCOFF.
llvm-svn: 204564
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
location that the next call emitLocation() would default to. Otherwise
setLocation() may wrongly believe that the current source file didn't
change, when in fact it did.
llvm-svn: 204517
at which that PCH imported each visible submodule of the module. Such locations
are needed when synthesizing macro directives resulting from the import.
llvm-svn: 204417
Variables with available_externally linkage can be dropped at will.
This causes link errors, since there are still references to the
instrumentation! linkonce_odr is almost equivalent, so use that
instead.
As a drive-by fix (I don't have an Elf system, so I'm not sure how to
write a testcase), use linkonce linkage for the instrumentation of
extern_weak functions.
<rdar://problem/15943240>
llvm-svn: 204408
These functions are in the profile runtime. PGO comes later.
Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.
<rdar://problem/15943240>
llvm-svn: 204390
We were 'allowing' the following import
@import Sub;
where Sub is a subframework of Foo and we had a -F path inside
Foo.framework/Frameworks and no module map file for Sub. This would
later hit assertion failures in debug builds.
Now we should correctly diagnose this as a module not found error.
llvm-svn: 204368
Amends r204300 to not try to test fixing a wchar_t* to "%ls", which we don't
do correctly anyway. In C mode, wchar_t is just a typedef for a normal
primitive integer type, not a distinct type like it is in C++. To make this
work correctly, we'll need to look for the wchar_t typedef, not just the
builtin type.
Should fix the buildbots.
llvm-svn: 204349
This change turns -fsanitize-memory-track-origins into
-fsanitize-memory-track-origins=[level] flag (keeping the old one for
compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly
detailed). See docs (part of this patch) for more info.
llvm-svn: 204346
The exception is return statements that include control-flow,
which are clearly doing something "interesting".
99% of the cases I examined for -Wunreachable-code that fired
on return statements were not interesting enough to warrant
being in -Wunreachable-code by default. Thus the move to
include them in -Wunreachable-code-return.
This simplifies a bunch of logic, including removing the ad hoc
logic to look for std::string literals.
llvm-svn: 204307
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
The spelling location of stringified strings is not a file location.
Optimally, we'll want to solve the problem (as the FIXME states) by
handing in the right FileEntry of the #include location.
llvm-svn: 204220
The hash itself is still the number of counters, which isn't all that
useful, but this separates the API changes from the actual
implementation of the hash and will make it easier to transition to
the ProfileData library once it's implemented.
llvm-svn: 204186
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
Test doesn't actually require production of an object file and for
some targets (e.g. hexagon) an assembler is not always available when
lit tests are run.
llvm-svn: 204144
warnings (warning or lack there of) as well since
blocks are another pattern for envoking other
designated initializers. // rdar://16323233
llvm-svn: 204081
In instrumentation-based profiling, we need a set of data structures to
represent the counters. Previously, these were built up during static
initialization. Now, they're shoved into a specially-named section so
that they show up as an array.
As a consequence of the reorganizing symbols, instrumentation data
structures for linkonce functions are now correctly coalesced.
This is the first step in a larger project to minimize runtime overhead
and dependencies in instrumentation-based profilng. The larger picture
includes removing all initialization overhead and making the dependency
on libc optional.
<rdar://problem/15943240>
llvm-svn: 204080
What's going on in the test case (without the patch applied) is this:
When the header is parsed, decltype(B()) is canonicalized to decltype(Y()),
because that was the first parsed equivalent decltype expression. Hence, the
TemplateSpecializationType for Id<decltype(B())> ends up with
SubstTemplateTypeParmType(T, decltype(Y())) as the AliasedType member.
When the PCH file is included and the AST reader reads Id<decltype(B())>, it
sees decltype(B()) before decltype(Y()). So, this time decltype(B()) ends up
being the canonical type for both decltypes, which leads to an assert violation
when the reader calls getSubstTemplateTypeParmType with the non-canonical
decltype(Y()) as the replacement type.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits, aemerson
Differential Revision: http://llvm-reviews.chandlerc.com/D3073
llvm-svn: 204005
Also relax unreachable 'break' and 'return' to not check for being
preceded by a call to 'noreturn'. That turns out to not be so
interesting in practice.
llvm-svn: 204000
Recent work on -Wunreachable-code has focused on suppressing uninteresting
unreachable code that center around "configuration values", but
there are still some set of cases that are sometimes interesting
or uninteresting depending on the codebase. For example, a dead
"break" statement may not be interesting for a particular codebase,
potentially because it is auto-generated or simply because code
is written defensively.
To address these workflow differences, -Wunreachable-code is now
broken into several diagnostic groups:
-Wunreachable-code: intended to be a reasonable "default" for
most users.
and then other groups that turn on more aggressive checking:
-Wunreachable-code-break: warn about dead break statements
-Wunreachable-code-trivial-return: warn about dead return statements
that return "trivial" values (e.g., return 0). Other return
statements that return non-trivial values are still reported
under -Wunreachable-code (this is an area subject to more refinement).
-Wunreachable-code-aggressive: supergroup that enables all these
groups.
The goal is to eventually make -Wunreachable-code good enough to
either be in -Wall or on-by-default, thus finessing these warnings
into different groups helps achieve maximum signal for more users.
TODO: the tests need to be updated to reflect this extra control
via diagnostic flags.
llvm-svn: 203994
complete. We hook into this check from a couple of other places (modules,
debug info) so it's not OK to elide the check if the type was already
complete.
llvm-svn: 203978
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
'init' methods which are unavailable. Subclasses of NSObject
have to implement such methods as a common pattern to prevent
user's own implementation. // rdar://16305460
llvm-svn: 203966
data members by addition of CXXDefaultInitExpr node to the initializer expression,
it has broken treatment of arc code for such initializations. Reviewed by John McCall.
// rdar://16299964
llvm-svn: 203935
This is because the PCH is tied to the module files, if one of the module files changes or gets removed
the build system should re-build the PCH file.
rdar://16321245
llvm-svn: 203885
This makes Clang take advantage of the recent IR addition of a
"failure" memory ordering requirement. As with the "success" ordering,
we try to emit just a single version if the expression is constant,
but fall back to runtime detection (to allow optimisation across
function-call boundaries).
rdar://problem/15996804
llvm-svn: 203837
Passing a pointer to an uninitialized memory buffer is normally okay,
but if the function is declared to take a pointer-to-const then it's
very unlikely it will be modifying the buffer. In this case the analyzer
should warn that there will likely be a read of uninitialized memory.
This doesn't check all elements of an array, only the first one.
It also doesn't yet check Objective-C methods, only C functions and
C++ methods.
This is controlled by a new check: alpha.core.CallAndMessageUnInitRefArg.
Patch by Per Viberg!
llvm-svn: 203822
const-qualified parameter type and the defined with a non-const-qualified
parameter type, the parameter is not const inside its body. Ensure that
the type we use when instantiating the body is the right one. Patch by
suyog sarda!
This is still rather unsatisfactory; it seems like it might be better to
instantiate at least the function parameters, and maybe the complete function
declaration, when we instantiate the definition for such a member function
(instead of reusing the declaration from inside the instantiated class
definition).
llvm-svn: 203741
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
Unfortunately, XFAIL applies to the entire file. Split the test into two
different units, enabling the proper application of XFAIL on the test which is
expected to fail on Windows.
llvm-svn: 203633
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
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
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
Some of this data had gotten out of date, so we weren't quite testing
what we thought we were. This also moves the outdated data test to its
own file to simplify regenerating the test data.
llvm-svn: 203546
These tests are logically related, but they're spread about several
different CodeGen directories. Consolidate them in one place to make
them easier to manage.
llvm-svn: 203541
Checking if the host arch is in the triple isn't quite correct. Change
the feature test to match llvm's, which made the same change in r193459.
llvm-svn: 203540
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
This started failing for me the last time someone modified the AST file
format. It would be nice if we could just have lit take care of the
module cache used during testing for us, but this helps in the meantime.
llvm-svn: 203511
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
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
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
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
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
Paul Robinson