This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
llvm-svn: 206640
The frontend option -fno-optimize-sibling-calls resolves to -cc1's
-mdisable-tail-calls, which is passed to the TargetMachine in the
backend. PassManagerBuilder was adding the -tailcallelim pass anyway.
Use a new DisableTailCalls option in PassManagerBuilder to disable tail
calls harder.
Requires the matching commit in LLVM that adds DisableTailCalls.
<rdar://problem/16050591>
llvm-svn: 206543
In preparation for using a binary format for instrumentation based
profiling, explicitly treat the test inputs as text and transform them
before running. This will allow us to leave the checked in files in
human readable format once the instrumentation format is binary.
No functional change.
llvm-svn: 206509
Summary:
This patch ensures that the lines of the block comments retain relative
column offsets. In order to do this WhitespaceManager::Changes representing
continuation of block comments keep a pointer on the change representing the
whitespace change before the block comment, and a relative column offset to this
change, so that the correct column can be reconstructed at the end of alignment
process.
Fixes http://llvm.org/PR19325
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D3408
llvm-svn: 206472
With BinPackParameters=false and Cpp11BracedListStyle=true (i.e. mostly
for Chromium):
Before:
const Aaaaaa aaaaa = {aaaaa, bbbbb, ccccc, ddddd, eeeee, ffffff,
ggggg, hhhhhh, iiiiii, jjjjjj, kkkkkk};
After:
const Aaaaaa aaaaa = {aaaaa,
bbbbb,
ccccc,
ddddd,
eeeee,
ffffff,
ggggg,
hhhhhh,
iiiiii,
jjjjjj,
kkkkkk};
This fixes llvm.org/PR19359. I am not sure we'll want this in all cases
in the long run, but I'll guess we'll get feedback on that.
llvm-svn: 206458
My first attempt to make sure HFAs were contiguous was in the block dealing
with padding registers, which meant it only triggered on the first stack-based
HFA. This should extend it to the rest as well.
Another part of PR19432.
llvm-svn: 206456
that looks like it might be an explicit specialization, don't recover as an
explicit specialization (bypassing the check that would reject that).
llvm-svn: 206444
The YAMLParser has its own escaped string representation, and does not
handle octal escape sequences. When writing the virtual file system to a
YAML file, use yaml::escape().
llvm-svn: 206443
specializations collect all arguments and not just the ones from the
class template partial specialization from which this class template
specialization was instantiated. The debug info does not represent the
partial specialization otherwise and so specialized parameters would
go missing.
rdar://problem/16636569.
llvm-svn: 206430
This reverts commit r206413.
This was proposed before, but it's not clear if this is really a good
idea:
http://reviews.llvm.org/D3034
llvm-svn: 206415
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
llvm-svn: 206401
The function hash should change when control flow changes. This patch
hashes the type of each AST node that affects counters, rather than just
counting how many there are. These types are combined into a small
enumerator that currently has 16 values.
The new hash algorithm packs the enums for consecutively visited types
into a `uint64_t`. In order to save space for new types, the types are
assumed to be 6-bit values (instead of 4-bit). In order to minimize
overhead for functions with little control flow, the `uint64_t` is used
directly as a hash if it never fills up; if it does, it's passed through
an MD5 context.
<rdar://problem/16435801>
llvm-svn: 206397
This is similar to how we treat assignments and seems to be generally
desirable.
Before:
llvm::errs() << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
llvm::errs() << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 206384
preventing me from seeing it initially). GCC doesn't use the unused
attribute on members for anything, so while it works to suppress Clang's
warning for an unused private member, it adds a GCC warning for the
attribute. =/ Silence Clang's warning with a void cast in the
constructor instead which doesn't trigger any complaints from GCC.
llvm-svn: 206373
This is a partial revert of 183015.
By not recognizing things like _setjmp we lose (returns_twice) attribute on
them, which leads to incorrect code generation.
Fixes PR16138.
llvm-svn: 206362
At one point, -fexceptions was a synonym for -fcxx-exceptions. While
the driver options still enables cxx-exceptions by default, the cc1
flag is purely about exception tables and this doesn't account for
objective C exceptions. Because of this, checking for the
cxx_exceptions feature in objective C++ often gives the wrong answer.
The cxx_exceptions feature should be based on the -fcxx-exceptions cc1
flag, not -fexceptions. Furthermore, at some point the tests were
changed to use cc1 even though they were testing the driver behaviour.
We're better off testing both the driver and cc1 here.
llvm-svn: 206352
Warn on std::abs() with unsigned argument.
Suggest std::abs as replacement for the C absolute value functions.
Suggest C++ headers if the specific std::abs overload is not found.
llvm-svn: 206340
alignment constraint rather than using the allocator function's over
alignment "feature". This was the only use of the "feature" which I plan
to remove next. =] Attaching the alignment to the type seems cleaner and
more principled anyways.
llvm-svn: 206324
This adds a warning that triggers when profile data doesn't match for
the source that's being compiled with -fprofile-instr-use=. This fires
only once per translation unit, as warning on every mismatched
function would be quite noisy.
llvm-svn: 206322
When instantiating an array that has an alignment attribute on it, we
were looking through the array type and only considering the element
type for the resulting alignment. We need to make sure we take the
array's requirements into account too.
llvm-svn: 206317
Sema does have a CUDALaunchBoundsAttr, but CodeGen was doing nothing with it.
This change translates CUDALaunchBoundsAttr to maxntidx and minctasm
metadata, which NVPTX then translates to the correct PTX directives.
Patch by Manjunath Kudlur.
llvm-svn: 206302
This implements clause C.8 of the AAPCS in the front-end, so that Clang
accurately knows when the registers run out and it has to insert padding before
the stack objects begin.
PR19432.
llvm-svn: 206296
Also removed spaces before colons as they don't seem to be used
frequently.
Before:
optional int32 b = 2
[(foo_options) = {aaaaaaaaaaaaaaaaaaa : 123 bbbbbbbbbbbbbbbbbbbbbbbb :
"baz"}];
After:
optional int32 b = 2 [(foo_options) = {aaaaaaaaaaaaaaaaaaa: 123,
bbbbbbbbbbbbbbbbbbbbbbbb:"baz"}];
llvm-svn: 206269
Specifically, for a nested block or lambda, don't try to put the single
statement body inline, if it exceeds the column limit.
This should not change any observable behavior (as those would never
have led to the 'best' solution), but significantly speeds up formatting
time.
This fixes llvm.org/PR18761. Formatting time goes down from ~100s to a
few ms.
llvm-svn: 206260
CapturedStmt was being ignored by instrumentation based profiling, and
its counters attributed to the containing function. Instead, we need
to treat this as a top level entity, like we do with blocks.
llvm-svn: 206231
To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
cache-path/<module hash>/Foo.pcm
to
cache-path/<module hash>/Foo-<hash of module map path>.pcm
In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary. For example, if module A
imports module B
first time:
clang -I /path/to/A -I /path/to/B ...
second time:
clang -I /path/to/A -I /different/path/to/B ...
will now rebuild A as expected.
* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.
llvm-svn: 206201
Currently the on disk hash table's key_iterator and data_iterator make
the assumption that the table data starts exactly four bytes after the
base of the table. This happens to be true for all of the tables we
currently iterate over, but not for all of the OnDiskHashTables we
currently use. For example, key_ and data_iterator would iterate over
meaningless data if they were used on the hash tables in PTHLexer.
We make the API safer by breaking this into two types. One doesn't
have the iterators, and the other must be told where the payload
starts.
llvm-svn: 206189
Summary: Add support for named values in the parser.
Reviewers: pcc
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3276
llvm-svn: 206176
Before:
if (aaaaaaaa && bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
After:
if (aaaaaaaa
&& bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
The same rule has already be implemented for BreakBeforeBinaryOperators
set to false in r205527.
llvm-svn: 206159
Now correctly formats:
{
int a;
void f() {
callme(some(parameter1,
<<<<<<< text by the vcs
parameter2),
||||||| text by the vcs
parameter2),
parameter3,
======= text by the vcs
parameter2, parameter3),
>>>>>>> text by the vcs
otherparameter);
}
}
llvm-svn: 206157
Parse of nested name spacifier is modified so that it properly recovers
if colon is mistyped as double colon in case statement.
This patch fixes PR15133.
Differential Revision: http://llvm-reviews.chandlerc.com/D2870
llvm-svn: 206135
If the C-style type cast is applied to the overloaded
function and the destination type is function type,
then Clang will crash with assertion failure. For example,
void foo(int);
void foo(int, int);
void bar() {
typedef void (ft)(int);
ft p = (ft)foo;
}
In this case, the overloaded function foo will be cast to
a function type, which should be considered as an error.
But, unfortunately, since the function resolution is using
canonical type, the matched function will be returned, and
result in SEGV.
This patch fixes this issue by removing the assertion and
add some error diagnostics as the one in static_cast.
llvm-svn: 206133
Previously, it was believed that #pragma vtordisp(0) would prohibit the
generation of any and all vtordisps.
In actuality, it only disables the generation of additional vtordisps.
This fixes PR19413.
llvm-svn: 206124
for CXXGlobalInit/Dtor helper functions.
This makes _GLOBAL__I_a regain its DW_AT_high/low_pc in the debug info.
Thanks to echristo for catching this!
llvm-svn: 206088
Until now we were generating duplicate counters for lambdas: one set
in the function where the lambda was declared and another for the
lambda itself. Instead, we should skip over the bodies of lambdas in
their containing contexts.
llvm-svn: 206081
A portion of the vtordisp computation that was previously unguarded by a
test for the declaration of user defined constructors/destructors was
erroniously adding vtordisps to things that shouldn't have them. This
patch correctly guards that codepath. In addition, it updates the
comments to make them more clear. Test case is included.
llvm-svn: 206077
The -fms-extensions option affects a number of subtle front-end C/C++
behaviors, and it would be useful to be able to distinguish MS keywords
from regular identifiers in the ms-extensions mode even if the triple
does not define a Windows target. It should make life easier if anyone
needs to port their Windows codes to elsewhere.
Differential Revision: http://reviews.llvm.org/D3034
llvm-svn: 206069
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
This patch updates the comments in RecordLayoutBuilder about record
layout in the MS-ABI. Also, I added a section about known
incompatibilities.
llvm-svn: 206010
In version 9 (VS2010) (and prior)? versions of msvc, if the last field
in a record was a bitfield padding equal to the size of the storage
class of that bitfield was added before each vbase and vtordisp. This
patch removes that feature from clang and updates the lit tests to
reflect it.
llvm-svn: 206004
Fixes a bug where unsigned numbers are read using strtol and strtoll.
I don't have a testcase because this bug is effectively unobservable
right now. To expose the problem in the hash, we would need a function
with greater than INT64_MAX counters, which we don't handle anyway. To
expose the problem in the function count, we'd need a function with
greater than INT32_MAX counters; this is theoretically observable, but
it isn't a practical testcase to check in.
An upcoming commit changes the hash to be non-trivial, so we'll get some
coverage eventually.
<rdar://problem/16435801>
llvm-svn: 206001
The vbptr is injected after the last non-virtual base lexographically
rather than the last non-virtual base in layout order. Test case
included. Also, some line ending fixes.
llvm-svn: 206000
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
llvm-svn: 205999
When __declspec(align()) is applied to a bitfield it affects the
alignment rather than the required alignment of the struct. The major
feature that this patch adds is that the alignment of the structure
obeys the alignment of __declspec(align()) from the bitfield over the
value specified in pragma pack.
Test cases are included.
The patch also includes some small cleanups in recordlayoutbuilder and
some cleanups to some lit tests, including line endings (but no
functionality change to lit tests)
llvm-svn: 205994
Emitting the PGO initialization in EmitGlobalFunctionDefinition is
inefficient, since this only has an effect once per module. We move
this to Release() with the rest of the once-per-module logic.
llvm-svn: 205977
sure that a debugger can find them when stepping through code,
for example from the included testcase:
12 int test_it() {
13 c = 1;
14 d = 2;
-> 15 a = 4;
16 return (c == 1);
17 }
18
(lldb) p a
(int) $0 = 2
(lldb) p c
(int) $1 = 2
(lldb) p d
(int) $2 = 2
and a, c, d are all part of the file static anonymous union:
static union {
int c;
int d;
union {
int a;
};
struct {
int b;
};
};
Fixes PR19221.
llvm-svn: 205952
If we crash, we raise a crash handler dialog, and that's really
annoying. Even though we can't emit correct IR until we have musttail,
don't crash.
llvm-svn: 205948
cxx-abi-dev came up with a way to disambiguate between different
keywords used in elaborated type specifiers.
This resolves certain collisions during mangling.
llvm-svn: 205943
Moving it into a struct makes things work because it implicitly marks
the function as inline. The struct is unnecessary if you explicitly
mark the function inline.
llvm-svn: 205935
This patch changes how we determine if padding is needed between two
bases in msvc compatibility mode. Test cases included.
In addition, a very minor change to the printing of structures to ease
lit testing.
llvm-svn: 205933
The idea is to give visibility to more type kinds, especially for getting
a better grasp of what appears as unexposed type kind with libclang.
Differential Revision: http://reviews.llvm.org/D3325
llvm-svn: 205921
* Adds an iterator_range interface to CallExpr to get the arguments
* Modifies SExpr such that it must be allocated in the Arena, and cannot be deleted
* Minor const-correctness and nullptr updates
* Adds some operator!= implementations to complement operator==
* Removes unused functionality
llvm-svn: 205915
More precisely keep all short annotations (<10 characters) on the same
line if possible. Previously, clang-format would only prefer to do so
for "const", "override" and "final". However, it seems to be generally
preferable, especially because some codebases have to wrap those in
macros for backwards compatibility.
Before:
void someLongFunction(int someLongParameter)
OVERRIDE {}
After:
void someLongFunction(
int someLongParameter) OVERRIDE {}
This fixes llvm.org/PR19363.
llvm-svn: 205845
This also includes some infrastructure to make it easier to build multi-argument
selectors, rather than trying to use string matching on each piece. There's a bit
more setup code, but less cost at runtime.
PR18908
llvm-svn: 205827
This patch adds support for the msvc pragmas section, bss_seg, code_seg,
const_seg and data_seg as well as support for __declspec(allocate()).
Additionally it corrects semantics and adds diagnostics for
__attribute__((section())) and the interaction between the attribute
and the msvc pragmas and declspec. In general conflicts should now be
well diganosed within and among these features.
In supporting the pragmas new machinery for uniform lexing for
msvc pragmas was introduced. The new machinery always lexes the
entire pragma and stores it on an annotation token. The parser
is responsible for parsing the pragma when the handling the
annotation token.
There is a known outstanding bug in this implementation in C mode.
Because these attributes and pragmas apply _only_ to definitions, we
process them at the time we detect a definition. Due to tentative
definitions in C, we end up processing the definition late. This means
that in C mode, everything that ends up in a BSS section will end up in
the _last_ BSS section rather than the one that was live at the time of
tentative definition, even if that turns out to be the point of actual
definition. This issue is not known to impact anything as of yet
because we are not aware of a clear use or use case for #pragma bss_seg
but should be fixed at some point.
Differential Revision=http://reviews.llvm.org/D3065#inline-16241
llvm-svn: 205810
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
Don't include input and output regs in clobbers. Prefix some
identifiers with __. Add a memory constraint to __readcr3 to prevent
reordering. This constraint is heavy handed, but conservatively
correct.
Thanks to PaX Team for the suggestions.
llvm-svn: 205778
Before AllowShortFunctionsOnASingleLine could either be true, merging
all functions, or false, merging no functions. This patch adds a third
value "Inline", which can be used to only merge short functions defined
inline in a class, i.e.:
void f() {
return 42;
}
class C {
void f() { return 42; }
};
llvm-svn: 205760
This patch is the first part of a significant refactoring that seeks to restore
sanity to way thread safety analysis deals with capability expressions. The
current patch merely provides an outline of the structure of the new system.
It's not yet connected to the actual analysis, so there's no change in
functionality.
llvm-svn: 205728
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
We already got the type alias correct (though I've included a test case
here) since Clang represents that like any other typedef - but type
alias templates weren't being handled.
llvm-svn: 205691
While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.
llvm-svn: 205668
which warns on compound conditionals that always evaluate to the same value.
For instance, (x > 5 && x < 3) will always be false since no value for x can
satisfy both conditions.
This patch also changes the CFG to use these tautological values for better
branch analysis. The test for -Wunreachable-code shows how this change catches
additional dead code.
Patch by Anders Rönnholm.
llvm-svn: 205665
Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.
Patch by Alex McCarthy, with an extra test from me.
llvm-svn: 205661
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
llvm-svn: 205653
See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.
Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?
llvm-svn: 205651
This introduces the definitions needed for the Windows on ARM target. Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment. The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.
llvm-svn: 205650
Visual Studio is the Integrated Development Environment. The toolchain is
generally referred to MSVC. Rename the target information to be more precise as
per the recommendation of Reid Kleckner.
llvm-svn: 205609
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
If all of our weights are zero when calculating branch weights, it
means we haven't profiled the code in question. Avoid creating a
metadata node that says all branches are equally likely in this case.
The test also checks constructs that hit the other createBranchWeights
overload. These were already working.
llvm-svn: 205606
If we ever want three or more aliases, at that point we should put MSVC
warning ids in DiagnosticGroups.td. We can use that to support #pragma
warning.
llvm-svn: 205598
This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3283
llvm-svn: 205591
By ignoring this pragma with a warning, we're essentially miscompiling
the user's program. WebKit / Blink use this pragma to disable dynamic
initialization and finalization of some static data, and running the
dtors crashes the program.
Error out for now, so that /fallback compiles the TU correctly with
MSVC. This pragma should be implemented some time this month, and we
can remove this hack.
llvm-svn: 205554
Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.
This provides some 3% speedup when preprocessing gcc.c as a single file.
The patch is wrong, it always uses SSE2, and when I fix that there's no speedup
at all. I am not sure where the 3% came from previously.
--Thi lie, and those below, will be ignored--
M Lex/Lexer.cpp
llvm-svn: 205548
No functionality change.
When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template). Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly).
This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272)
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?"
In my reckless youth, I chose to ignore that comment. With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;)
llvm-svn: 205543
Don't allow the RHS of an operator to be split over multiple
lines unless there is a line-break right after the operator.
Before:
if (aaaa && bbbbb || // break
cccc) {
}
After:
if (aaaa &&
bbbbb || // break
cccc) {
}
In most cases, this seems to increase readability.
llvm-svn: 205527
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
meaningful to odr-use the VarDecl inside a variable template. (Separately, it'd
be nice to track referenced-ness for templates, and warn on unused ones, but
that's really a distinct issue...)
Move a test that generates and tests a warning-suppressing error out to its own
test file, so it doesn't have weird effects on the other tests in the same file.
llvm-svn: 205448
This was committed 4 years ago in 108916 with insufficient testing to
explain why the "getTypeAsWritten" case was appropriate. Experience says
that it isn't - the presence or absence of an explicit instantiation
declaration was causing this code to generate either i<int> or i<int,
int>.
That didn't seem to be a useful distinction, and omitting the template
arguments was destructive to debuggers being able to associate the two
types across translation units or across compilers (GCC, reasonably,
never omitted the arguments).
llvm-svn: 205447
Summary:
Add support for named values in the parser.
This allows injection of arbitrary constants using a custom Sema object.
Completions are not supported right now.
Will be used by clang_query to support the 'let' command.
Usage example:
clang_query> let unique_ptr recordDecl(hasName("unique_ptr"))
clang_query> match varDecl(hasType(unique_ptr))
Reviewers: klimek, pcc
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3229
llvm-svn: 205419
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
We don't want to encourage the code to emit a lexical block for
a function that needs one in order for the line table to change,
we need to grab the line information from the body of the pattern
that we were instantiated from, this code should do that.
Modify the test case to ensure that we're still looking in the
right place for all of the scopes and also that we haven't
created a lexical block where we didn't need one.
llvm-svn: 205368
If we're trying to get the zero element region of something that's not a region,
we should be returning UnknownVal, which is what ProgramState::getLValue will
do for us.
Patch by Alex McCarthy!
llvm-svn: 205327
The MS ABI forces us into catch-22 when it comes to functions which
return types which are local:
- A function is mangled with it's return type.
- A type is mangled with it's surrounding context.
Avoid this by mangling auto and decltype(autp) directly into the
function's return type. Using this mangling has the double advantage of
being compatible with the C++ standard without crashing the compiler.
N.B. For the curious, the MSVC mangling leads to collisions amongst
template functions and either crashes when faced with local types or is
otherwise incapable of returning them.
llvm-svn: 205282
Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
llvm-svn: 205272
Fallout from r205261, ensure it doesn't matter how we disable compressed
debug info, even if zlib is missing and that we warn when we don't have
zlib and don't warn when we do, all while silently suppressing these
tests on the systems they weren't intended for...
llvm-svn: 205271
It turns out that the ranges where the '?' <letter> manglings occur are
identical to the ranges of ASCII characters OR'd with 0x80.
Thanks to Richard Smith for the insight!
No functional change.
llvm-svn: 205270
Code review feedback from Eric Christopher on r204261.
I didn't want to go into too much detail (the revision history should
provide the full stuff) - but I can add more if that's preferred.
Also moved this up to right by the construction of the MCAsmInfo so
there's less chance that other things might sneak in in between.
llvm-svn: 205267
For those playing at home this produced some fairly subtle behavior. The
sections created in InitMCObjectFileInfo were created without compressed
debug info (a mistake, but not necessarily /broken). Since these
sections were almost always referenced by the existing MCSection object,
this almost worked.
This got weird when we got to handling the relocations for a section.
See ELFObjectWriter::WriteSection where we compute the true section for
a relocation section by simply stripping the ".rela" prefix and then
looking up that section - doing so hit the compression codepath, looked
up .zdebug_blah and found a newly constructed empty section... thus,
things got weird.
This is untestable without a cross-project test (let me know if people
would prefer that to no testing).
llvm-svn: 205261
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
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.
llvm-svn: 205181
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
The delta between '\xe1' and '\xc1' is equivalent to the one between 'a'
and 'A'. This allows us to reuse the computation between '\xe1' and
'\xfa' for the '\xc1' to '\xda' case.
No functionality change.
llvm-svn: 205128
Some ABIs and C++ libraries may make different trade-offs in how RTTI
is emitted (currently with respect to visibility and so on). This
implements one scheme, as used by ARM64.
llvm-svn: 205101
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
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to read little endian data
from a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205062
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to write little endian data
to an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205061
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
Rather than rolling our own functions to read little endian data from
a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205045
Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205044
-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
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.
llvm-svn: 204952
While these might make sense for some rule (e.g. break after multi-line
operand), they generally appear ugly and confusing.
Before:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" + bbbbbb)
After:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" +
bbbbbb)
llvm-svn: 204937
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
Store the number of clauses and children of OMPExecutableDirective and dynamically compute the locations of corresponding arrays.
http://llvm-reviews.chandlerc.com/D2977
llvm-svn: 204933
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.
llvm-svn: 204910
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
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).
llvm-svn: 204722
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
Additional clarification from Uli for the background on _CALL_ELF:
"Historically GCC has provided various _CALL_... predefines depending on the
ABI currently being compiled for. (_CALL_SYSV,_CALL_AIXDESC, _CALL_DARWIN )
When we needed a new define for the current ABI, we decided on using _CALL_ELF
since the official name of the ABI is the OpenPower ElfV2 ABI, with the
current Linux ABI retro-actively being renamed the ELFv1 ABI
and so we decided on using _CALL_ELF to identify the Linux (+BSD etc.) ELF ABI,
with _CALL_ELF=1 for the v1 ABI and _CALL_ELF=2 for the v2 ABI.
(Note that this matches the gcc compiler switch -mabi=elfv1 vs. -mabi=elfv2)."
In code, a (_CALL_ELF==2) check will indicate when the ELFv2 ABI is
to be used. This is the desired default for the PPC64 LE target.
llvm-svn: 204627
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
Justin Bogner