Justin Bogner [Wed, 25 Mar 2015 04:13:49 +0000 (04:13 +0000)]
InstrProf: Handle whitespace and comments at the ends of macros
When we try to find the end loc for a token, we have to re-lex the
token. This was running into a problem when we'd store the end loc of
a macro's coverage region, since we wouldn't actually be at the
beginning of a token when we tried to re-lex it, leading us to do
silly things (and eventually assert) when whitespace or comments
followed.
This pushes our use of getPreciseTokenLocEnd earlier, so that we won't
call it when it doesn't make sense to. It also removes an unnecessary
adjustment by 1 that was working around this problem in some cases.
Chandler Carruth [Wed, 25 Mar 2015 01:02:12 +0000 (01:02 +0000)]
[Modules] Make the DeclUpdates map be processed in insertion order.
This fixes my stress tests non-determinism so far. However, I've not
started playing with templates, friends, or terrible macros. I've found
at least two more seeming instabilities and am just waiting for a test
case to actually trigger them.
Chandler Carruth [Wed, 25 Mar 2015 00:34:51 +0000 (00:34 +0000)]
[Modules] When writing out the on-disk hash table for the decl context
lookup tables, we need to establish a stable ordering for constructing
the hash table. This is trickier than it might seem.
Most of these cases are easily handled by sorting the lookup results
associated with a specific name that has an identifier. However for
constructors and conversion functions, the story is more complicated.
Here we need to merge all of the constructors or conversion functions
together and this merge needs to be stable. We don't have any stable
ordering for either constructors or conversion functions as both would
require a stable ordering across types.
Instead, when we have constructors or conversion functions in the
results, we reconstruct a stable order by walking the decl context in
lexical order and merging them in the order their particular declaration
names are encountered. This doesn't generalize as there might be found
declaration names which don't actually occur within the lexical context,
but for constructors and conversion functions it is safe. It does
require loading the entire decl context if necessary to establish the
ordering but there doesn't seem to be a meaningful way around that.
Many thanks to Richard for talking through all of the design choices
here. While I wrote the code, he guided all the actual decisions about
how to establish the order of things.
No test case yet because the test case I have doesn't pass yet -- there
are still more sources of non-determinism. However, this is complex
enough that I wanted it to go into its own commit in case it causes some
unforseen issue or needs to be reverted.
Ahmed Bougacha [Tue, 24 Mar 2015 23:44:42 +0000 (23:44 +0000)]
[CodeGen] Support native half inc/dec amounts.
We previously defaulted to long double, but it's also possible to have
a half inc/dec amount, when LangOpts NativeHalfType is set.
Currently, that's only true for OpenCL.
Chandler Carruth [Tue, 24 Mar 2015 21:44:25 +0000 (21:44 +0000)]
[Modules] Stop creating timestamps for the modules cache and trying to
prune it when we have disabled implicit module generation and thus are
not using any cached modules.
Also update a test of explicitly generated modules to pass this CC1 flag
correctly.
This fixes an issue where Clang was dropping files into the source tree
while running its tests.
Chandler Carruth [Tue, 24 Mar 2015 21:18:10 +0000 (21:18 +0000)]
[Modules] Start making explicit modules produce deterministic output.
There are two aspects of non-determinism fixed here, which was the
minimum required to cause at least an empty module to be deterministic.
First, the random number signature is only inserted into the module when
we are building modules implicitly. The use case for these random
signatures is to work around the very fact that modules are not
deterministic in their output when working with the implicitly built and
populated module cache. Eventually this should go away entirely when
we're confident that Clang is producing deterministic output.
Second, the on-disk hash table is populated based on the order of
iteration over a DenseMap. Instead, use a MapVector so that we can walk
it in insertion order.
I've added a test that an empty module, when built twice, produces the
same binary PCM file.
Sanjay Patel [Tue, 24 Mar 2015 20:35:24 +0000 (20:35 +0000)]
Removing a CHECK that is about to go wrong.
I'm about to commit a patch for:
http://reviews.llvm.org/D8567
That patch will break this one existing test case in Clang.
I'm not sure if this file is intending to create a Clang
dependency on the LLVM IR optimizer, but that's the
consequence of specifying -O3 on this test file.
My hope is to avoid buildbot rage by removing this check,
committing the LLVM patch, and then fixing this check.
I don't know how to make a simultaneous commit to Clang
and LLVM.
I will commit the correct CHECK line fix for this test
shortly.
Richard Smith [Tue, 24 Mar 2015 06:36:48 +0000 (06:36 +0000)]
[modules] Deserialize CXXCtorInitializer list for a constructor lazily.
Previously we'd deserialize the list of mem-initializers for a constructor when
we deserialized the declaration of the constructor. That could trigger a
significant amount of unnecessary work (pulling in all base classes
recursively, for a start) and was causing problems for the modules buildbot due
to cyclic deserializations. We now deserialize these on demand.
This creates a certain amount of duplication with the handling of
CXXBaseSpecifiers; I'll look into reducing that next.
Ben Langmuir [Tue, 24 Mar 2015 04:43:52 +0000 (04:43 +0000)]
A couple of readASTFileSignature improvements (NFC)
* Strength reduce a std::function to a function pointer,
* Factor out checking the AST file magic number,
* Add a brief doc comment to readAStFileSignature
Richard Smith [Tue, 24 Mar 2015 02:49:55 +0000 (02:49 +0000)]
[modules] More removal of unnecessary deserialization of lexical decls.
Even if we have no external visible declarations, we may still have external
lexical decls that lookup() would import to fill its lookup table. It's simpler
and faster to always take the no-deserialization path through noload_lookup.
Richard Smith [Tue, 24 Mar 2015 02:44:20 +0000 (02:44 +0000)]
When looking for lexical decls from an external source, check all contexts
rather than just the primary context. This is technically correct but results
in no functionality change (in Clang nor LLDB) because all users of this
functionality only use it on single-context DCs.
Eli Bendersky [Mon, 23 Mar 2015 23:49:41 +0000 (23:49 +0000)]
Cleanup: no need to pass DefinitionKind into ParseCXXInlineMethodDef
All ParseCXXInlineMethodDef does with it is assign it on the ParsingDeclarator.
Since that is passed in as well, the (single) caller may as well set the
DefinitionKind, thus simplifying the code.
Alexey Samsonov [Mon, 23 Mar 2015 23:14:05 +0000 (23:14 +0000)]
[UBSan] Use shared library for UBSan on OS X (Clang part).
Summary:
UBSan is now used in the same way as ASan, and is supported on
OSX and on iOS simulator. At the moment ASan and UBSan can't be used
together due to PR21112, but I hope to resolve it soon by
embedding UBSan into ASan.
Yunzhong Gao [Mon, 23 Mar 2015 20:41:42 +0000 (20:41 +0000)]
Adds a warning for unrecognized argument to #pragma comment() on PS4.
PS4 target recognizes the #pragma comment() syntax as in -fms-extensions, but
only handles the case of #pragma comment(lib). This patch adds a warning if any
other arguments are encountered.
This patch also refactors the code in ParsePragma.cpp a little bit to make it
more obvious that some codes are being shared between -fms-extensions and PS4.
Get rid of "libclang_rt.san" library that used to contain
sanitizer_common pieces required by UBSan if it's used in a standalone
mode. Instead, build two variants of UBSan runtime: "ubsan" and
"ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx").
Later "ubsan" and "ubsan_cxx" libraries will go away, as they will
embedded it into corresponding ASan runtimes.
Ahmed Bougacha [Mon, 23 Mar 2015 17:54:16 +0000 (17:54 +0000)]
[CodeGen] Properly support the half FP type with non-native operations.
On AArch64, the -fallow-half-args-and-returns option is the default.
With it, the half type is considered legal (rather than the i16 used
normally for __fp16), but no operation is, except conversions and
load/stores and such.
The previous behavior was tantamount to saying LangOpts.NativeHalfType
was implied by LangOpts.HalfArgsAndReturns, which isn't true.
Instead, teach the various parts of CodeGen that already know about
half (using the intrinsics or not) about this weird in-between case,
where the "half" type is legal, but operations on it aren't.
This is a smaller intermediate step to the end-goal of removing the
intrinsic, always using "half", and letting the backend legalize.
Builds on r232968.
rdar://20045970, rdar://17468714
Differential Revision: http://reviews.llvm.org/D8367
Ahmed Bougacha [Mon, 23 Mar 2015 17:48:07 +0000 (17:48 +0000)]
[CodeGen] Convert double -> __fp16 in one step.
Fix the CodeGen so that for types bigger than float, instead of
converting to fp16 via the sequence "InTy -> float -> fp16", we
perform conversions in just one step. This avoids the double
rounding which potentially changes results from a natural
IEEE-754 operation.
rdar://17594379, rdar://17468714
Differential Revision: http://reviews.llvm.org/D4602
Part of: http://reviews.llvm.org/D8367
void<copy_func>(void *LHSArg, void *RHSArg) {
Dst = (void * [n])(LHSArg);
Src = (void * [n])(RHSArg);
Dst[0] = Src[0];
... Dst[n] = Src[n];
}
```
All list items from all 'copyprivate' clauses are gathered into single <copyprivate list> (<copyprivate_list_size> is a size in bytes of this list) and <copy_func> is used to propagate values of private or threadprivate variables from the 'single' region to other implicit threads from outer 'parallel' region.
Differential Revision: http://reviews.llvm.org/D8410
Richard Smith [Mon, 23 Mar 2015 03:25:59 +0000 (03:25 +0000)]
[modules] Remove redundant import of lexical decls when building a lookup table
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
Benjamin Kramer [Sun, 22 Mar 2015 21:57:53 +0000 (21:57 +0000)]
[ASTMatchers] Factor wrapping matcher classes into a common base class.
The deduplication here is negligible, but it allows the compiler to
skip emission of many templated base class destructors. Shrinks
clang-query by 53k. No functionality change intended.
David Majnemer [Sun, 22 Mar 2015 08:39:22 +0000 (08:39 +0000)]
MS ABI: Implement driver-level support for thread-safe statics
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
Alexander Musman [Sat, 21 Mar 2015 10:12:56 +0000 (10:12 +0000)]
[OPENMP] CodeGen of the 'linear' clause for the 'omp simd' directive.
The linear variable is privatized (similar to 'private') and its
value on current iteration is calculated, similar to the loop
counter variables.
Differential revision: http://reviews.llvm.org/D8375
Eric Christopher [Sat, 21 Mar 2015 06:15:15 +0000 (06:15 +0000)]
Add CodeGen support for adding cpu attributes on functions based on
the target-cpu, if different from the triple's cpu, and
target-features as they're written that are passed down from the
driver.
Together with LLVM r232885 this should allow the LTO'ing of binaries
that contain modules compiled with different code generation options
on a subset of architectures with full backend support (x86, powerpc,
aarch64).
Richard Smith [Sat, 21 Mar 2015 00:58:54 +0000 (00:58 +0000)]
[modules] When either redecl chain merging or an update record causes us to
give an exception specification to a declaration that didn't have an exception
specification in any of our imported modules, emit an update record ourselves.
Without this, code importing the current module would not see an exception
specification that we could see and might have relied on.
Don't claim exception related arguments when looking at RTTIMode
Summary:
We were claiming the -f*exceptions arguments when looking for the
RTTIMode. This makes us not warn about unused arguments if compiling a C
file with -fcxx-exceptions.
This patch fixes it by not claiming the exception-related arguments at
that point.
Jordan Rose [Fri, 20 Mar 2015 21:12:27 +0000 (21:12 +0000)]
[analyzer] RetainCountChecker: Don't assume +0 for ivars backing readonly properties.
Similarly, don't assume +0 if the property's setter is manually implemented.
In both cases, if the property's ownership is explicitly written, then we /do/
assume the ivar has the same ownership.
Alexey Samsonov [Fri, 20 Mar 2015 18:45:06 +0000 (18:45 +0000)]
[UBSan] Don't allow to use UBSan with anything except for ASan.
We are not able to make a reliable solution for using UBSan together
with other sanitizers with runtime support (and sanitizer_common).
Instead, we want to follow the path used for LSan: have a "standalone"
UBSan tool, and plug-in UBSan that would be explicitly embedded into
specific sanitizers (in short term, it will be only ASan).
Alexey Bataev [Fri, 20 Mar 2015 07:21:46 +0000 (07:21 +0000)]
[MSVC] Explicit specializations can be declared in any namespace (fix for http://llvm.org/PR13738)
MS compiler emits no errors in case of explicit specializations outside declaration enclosing namespaces, even when language extensions are disabled.
The patch is to suppress errors and emit extension warnings if explicit specializations are not declared in the corresponding namespaces.
This fixes PR13738.
Justin Bogner [Fri, 20 Mar 2015 06:34:38 +0000 (06:34 +0000)]
InstrProf: Make profile variables private to reduce binary size overhead
When we instrument a program for profiling, we copy the linkage of an
instrumented function so that our datastructures merge in the same way
as the function. This avoids redundant copies for things like
linkonce, but ends up emitting names we never need to reference for
normal and internal symbols. Promoting internal and external linkage
to private for these variables reduces the size overhead of profiling
drastically.
Richard Smith [Fri, 20 Mar 2015 02:17:21 +0000 (02:17 +0000)]
[modules] Remove some redundant work when building a lookup table for a DeclContext.
When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.
This unnecessary work was papering over some other bugs:
- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.
- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).
A WIP patch to turn on stricter `DIDescriptor` accessor checks fires
here; it's obvious from the code that `T` can be null, so add an
explicit check. Caught by dozens of current testcases.
Reid Kleckner [Fri, 20 Mar 2015 00:31:07 +0000 (00:31 +0000)]
C++14: Disable sized deallocation by default due to ABI breakage
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
David Majnemer [Fri, 20 Mar 2015 00:02:27 +0000 (00:02 +0000)]
Don't crash-on-valid when an inline function is friend of class template
We assumed that the most recent declaration of an inline function would
also be inline. However, a more recent declaration can come from a
friend declaration in a class template that is instantiated at the
definition of the function.
Chandler Carruth [Thu, 19 Mar 2015 22:39:51 +0000 (22:39 +0000)]
[Modules] Implement __builtin_isinf_sign in Clang.
Somehow, we never managed to implement this fully. We could constant
fold it like crazy, including constant folding complex arguments, etc.
But if you actually needed to generate code for it, error.
I've implemented it using the somewhat obvious lowering. Happy for
suggestions on a more clever way to lower this.
Now, what you might ask does this have to do with modules? Fun story. So
it turns out that libstdc++ actually uses __builtin_isinf_sign to
implement std::isinf when in C++98 mode, but only inside of a template.
So if we're lucky, and we never instantiate that, everything is good.
But once we try to instantiate that template function, we need this
builtin. All of my customers at least are using C++11 and so they never
hit this code path.
But what does that have to do with modules? Fun story. So it turns out
that with modules we actually observe a bunch of bugs in libstdc++ where
their <cmath> header clobbers things exposed by <math.h>. To fix these,
we have to provide global function definitions to replace the macros
that C99 would have used. And it turns out that ::isinf needs to be
implemented using the exact semantics used by the C++98 variant of
std::isinf. And so I started to fix this bug in libstdc++ and ceased to
be able to compile libstdc++ with Clang.
David Majnemer [Thu, 19 Mar 2015 21:54:30 +0000 (21:54 +0000)]
MS ABI: Implement the MSVC 2015 scheme for scope disambiguation
consider C++ that looks like:
inline int &f(bool b) {
if (b) {
static int i;
return i;
}
static int i;
return i;
}
Both 'i' variables must have distinct (and stable) names for linkage
purposes. The MSVC 2013 ABI would number the variables using a count of
the number of scopes that have been created. However, the final 'i'
returns to a scope that has already been created leading to a mangling
collision.
MSVC 2015 fixes this by giving the second 'i' the name it would have if
it were declared before the 'if'. However, this results in ABI breakage
because the mangled name, in cases where there was no ambiguity, would
now be different.
We implement the new behavior and only enable it if we are targeting the
MSVC 2015 ABI, otherwise the old behavior will be used.
This way, one cannot accidentally call a function that isn't available
everywhere. Having to add the redeclaration will hopefully remind the user
to add an explicit respondsToSelector: call as well.
Some projects build against old SDKs to get this effect, but building against
old SDKs suppresses some bug fixes -- see http://crbug.com/463171 for examples.
The hope is that SDK headers are annotated well enough with availability
attributes that new SDK + this warning offers the same amount of protection
as using an old SDK.
Benjamin Kramer [Thu, 19 Mar 2015 16:06:49 +0000 (16:06 +0000)]
Devirtualize Attr and all subclasses.
We know all subclasses in tblgen so just generate a giant switch for
the few virtual methods or turn them into a member variable using spare
bits. The giant jump tables aren't pretty but still much smaller than
a vtable for every attribute, shrinking Release+Asserts clang by ~400k.
Also halves the size of the Attr base class. No functional change
intended.
projects / clang / log