Hans Wennborg [Fri, 28 Mar 2014 20:45:05 +0000 (20:45 +0000)]
Try to fix the cl-options.c test on ARM bots
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:
Objective-C. revert r204965. This will make
-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.
-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.
Use the new Windows environment for target detection
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.
Aaron Ballman [Thu, 27 Mar 2014 20:19:24 +0000 (20:19 +0000)]
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
David Tweed [Thu, 27 Mar 2014 16:34:11 +0000 (16:34 +0000)]
Enforce the restriction that a parameter to a kernel function
cannot be a pointer to the private address space (as clarified
in the OpenCL 1.2 specification).
Dmitri Gribenko [Thu, 27 Mar 2014 15:40:39 +0000 (15:40 +0000)]
Comment parsing: when comment ranges are deserialized from multiple modules,
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.
Rafael Espindola [Thu, 27 Mar 2014 15:27:20 +0000 (15:27 +0000)]
Handle and warn on aliases to weak aliases.
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.
Chandler Carruth [Thu, 27 Mar 2014 10:45:22 +0000 (10:45 +0000)]
[cleanup] Stop specifying size overrides for BumpPtrAllocators.
These don't seem to have any real point. Let's start with
IndexingContext. I can't come up with any conceivable reason to have
many hundereds of thousands of these alive in an address space which
would make the 4x difference in allocated (but unused) memory for the
string scratch buffer a significant memory usage problem.
The EditedSource one is somewhat more surprising. This is an 8x increase
in the memory allocated (but not used) per editted source file. However,
for this to realistically be a problem, you would need to have over half
a million editted source files in a single address space, and even that
would only really have problems on 32-bit Windows where you really only
have 2gb of virtual address space. And what's more important, the fix to
this if it is actually an issue shouldn't be to shrink the allocator's
size, it is to pass a single allocator into *many* edited source file
objects and let them share the memory.
These were the only two uses of custom sized BumpPtrAllocators
(excluding ones in the JIT using a custom allocation strategy) in all of
LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this
complexity in the primary BumpPtrAllocator at all and am planning to
remove it.
Reid Kleckner [Thu, 27 Mar 2014 00:00:03 +0000 (00:00 +0000)]
MS asm: Filter out fpsw clobbers
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.
Eric Christopher [Wed, 26 Mar 2014 23:09:30 +0000 (23:09 +0000)]
Just call getContextDescriptor to get the context for subprograms
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.
Objective-C. Fixes a bogus warning on unimplemented
selectors because we were not going through entire
elements in list of all implemented selectors.
// rdar://16428638
Logan Chien [Wed, 26 Mar 2014 17:35:01 +0000 (17:35 +0000)]
Fix atomic libcall.
This commit fixes a cast instruction assertion failure
due to the incompatible type cast. This will only happen when
the target requires atomic libcalls.
Jordan Rose [Wed, 26 Mar 2014 17:05:46 +0000 (17:05 +0000)]
[analyzer] Handle the M_ZERO and __GFP_ZERO flags in kernel mallocs.
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.
Paul Robinson [Wed, 26 Mar 2014 16:40:43 +0000 (16:40 +0000)]
Recommit r204493 with a fix to look in both clang and llvm directories.
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.
Reid Kleckner [Wed, 26 Mar 2014 15:38:33 +0000 (15:38 +0000)]
-fms-extensions: Add __va_start builtin, which is used for x64
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*.
Move the -i[no-]system-prefix options from CC1Options.td to Options.td.
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.
Bob Wilson [Tue, 25 Mar 2014 23:26:31 +0000 (23:26 +0000)]
[PGO] Add simplified branch weights for Objective-C for-collection loops.
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.
Benjamin Kramer [Tue, 25 Mar 2014 18:02:07 +0000 (18:02 +0000)]
Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math
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.
Jordan Rose [Tue, 25 Mar 2014 17:10:58 +0000 (17:10 +0000)]
[analyzer] Don't track retain counts of objects directly accessed through ivars.
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.
Manuel Klimek [Tue, 25 Mar 2014 14:39:26 +0000 (14:39 +0000)]
Fixes a bug in DynTypedNode.
Two DynTypedNodes can be equal if they do not have the same node type,
because DynTypedNodes for the same underlying object might have been
created from different types (for example, Decl vs VarDecl).
Richard Smith [Tue, 25 Mar 2014 01:14:22 +0000 (01:14 +0000)]
Save out a correct lookup table if a lookup table entry is stale (it contains
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.
Richard Smith [Tue, 25 Mar 2014 00:34:21 +0000 (00:34 +0000)]
If a DeclContext's lookups need to be reconciled, and we're given external declarations for a name, reconcile first. Otherwise, when we come to reconcile, we'll ask for external declarations for that name again. No functionality change intended.
David Majnemer [Mon, 24 Mar 2014 21:43:36 +0000 (21:43 +0000)]
MS ABI: Eliminate Duplicate Strings
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.
Warren Hunt [Mon, 24 Mar 2014 21:37:27 +0000 (21:37 +0000)]
[MS-ABI] Drop Special Layout in 64-bit mode.
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.
projects / clang / log