The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
llvm-svn: 202131
This allows the 'name' field to contain a path, like
{ 'type': 'directory',
'name': '/path/to/dir',
'contents': [ ... ] }
which not only simplifies reading and writing these files (for humans),
but makes it possible to easily modify locations via textual
replacement, which would not have worked in the old scheme.
E.g. sed s:<ROOT>:<NEW ROOT>
llvm-svn: 202109
Take advantage of CharUnits::alignmentAtOffset instead of calculating it
by hand.
Differential Revision: http://llvm-reviews.chandlerc.com/D2862
llvm-svn: 202098
Previously the X86 backend would look for the sret attribute and handle
this for us. inalloca takes that all away, so we have to do the return
ourselves now.
llvm-svn: 202097
When calculating the preferred alignment of a type, consider if a alignment
attribute came from a typedef declaration. If one did, do not naturally align
the type.
Patch by Stephan Tolksdorf, with a little tweaking and an additional testcase by me.
llvm-svn: 202088
We were previously checking at every destructor declaration, but that was a bit
excessive. Since the deleting destructor is emitted with the vtable, do the
check when the vtable is marked used.
Differential Revision: http://llvm-reviews.chandlerc.com/D2851
llvm-svn: 202046
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
We still don't use the PGO to set branch weights for these loops, but at
least this keeps the compiler from crashing. <rdar://problem/16137778>
llvm-svn: 202002
- Only include offsets with local (in function scope) symbols, where we don't encode scoping
- Only include the filename with non-system symbols. Presumably the system headers will not provide conflicting definitions.
rdar://15976823
llvm-svn: 201990
The DiagnosticBuilder's lifetime in parser typo recovery was overlapping with
the subsequent consume which can itself emit PP diagnostics.
Patch by Olivier Goffart!
llvm-svn: 201965
The integrated assembler is a feature. This makes the new flags the default
option, and the previous versions aliases. Ideally, at some point the aliases
would be entirely removed.
llvm-svn: 201963
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
This re-applies the previous version of the patch with a renaming of the driver
option to the public name rather than the internal name (-target vs -triple).
The actual failure is fixed separately of an overly aggressive negative pattern
match in the MIPS driver tests. It also fixes the incorrect test for targets
that have the integrated assembler disabled by default.
llvm-svn: 201960
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
llvm-svn: 201952
The language forbids defining enums in prototypes, so this check is normally
redundant, but if an enum is defined during template instantiation it should
not be added to the prototype scope.
While at it, clean up the code that deals with tag definitions in prototype
scope and expand the visibility warning to cover the case where an anonymous
enum is defined.
Differential Revision: http://llvm-reviews.chandlerc.com/D2742
llvm-svn: 201927
A recent change caused multi-dimensional arrays not to be handled
correctly, this patch fixes that. Also, it adds a lit test for
multi-dimensional arrays.
llvm-svn: 201917
It was previously thought that Sema::InstantiateClass could not fail
from within this point in instantiate.
However, it can happen if the class is invalid some way (i.e. invalid
base specifier).
This fixes PR18907.
Differential Revision: http://llvm-reviews.chandlerc.com/D2850
llvm-svn: 201913
In particular, if we see an @property within the @interface of a class
conforming to a protocol with this attribute, we treat that as
if the implementation were available, per the rules of default
property synthesis.
llvm-svn: 201911
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
Provides a way to create a virtual file system using a YAML file that
supports mapping a file to a path on an 'external' file system. The
external file system will typically be the 'real' file system, but for
testing it can be changed.
A future patch will add a clang option to allow the user to specify such
a file and overlay it, but for now this code is only exercised by the
unit tests.
Differential Revision: http://llvm-reviews.chandlerc.com/D2835
llvm-svn: 201905
Because GCC incorrectly defines _mm_prefetch to take anything that casts
to void*, people have started using that behavior. The previous patch
that made _mm_prefetch actually take a const char * broke compatibility
with existing code. This update to the patch leaves the macro that
defines _mm_prefetch with the (void*) cast when _MSC_VER is not defined.
llvm-svn: 201901
We're going to extend DiagnoseUnimplementedProperties shortly to look for more cases
that aren't handled by default property synthesis.
llvm-svn: 201878
This extends the intrinsic lookup table format slightly, and adds
entries for use the shared ARM/AArch64 definitions. The benefit is
currently smaller than for the SISD intrinsics (there's more custom
code implementing this set), but a few lines are saved and there's
scope for future expansion.
llvm-svn: 201848
This extracts the table-driven intrinsic lookup phase into a separate
function, to be used by EmitCommonNeonBuiltinExpr soon.
It also simplifies the logic used in that lookup, since VectorCastArgN
and ScalarArgN were actually identical.
llvm-svn: 201847
Added two new options for -mfpu when targetting ARM:
* fpv4-sp-d16
* fp4-sp-d16
The first is the same spelling as gcc.
The lack of a leading `v' is correct, this is consistent with ARM's
documentation and gcc's spelling of the option.
llvm-svn: 201846
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
Virtual methods expect 'this' to point to the vfptr containing the
virtual method, and this extends to virtual member pointer thunks. The
relevant vfptr is always at offset zero on entry to the thunk, and no
this adjustment is needed.
Previously we would not include the vfptr adjustment in the member
pointer, and we'd look at the vfptr offset when loading from the vftable
in the thunk.
Fixes PR18917.
llvm-svn: 201835
Slight change to the way zero-sized sub-objects are tracked in the
presence of virtual bases.
In addition we correctly distinguish between dsize and nvsize.
addresses http://llvm.org/bugs/show_bug.cgi?id=18826
Unit tests are included.
llvm-svn: 201832
There is no bound architecture for the dsymutil action in the driver. Trying
to check various properties of the target will cause an assertion failure
because the target doesn't get initialized without a bound architecture.
<rdar://problem/16111555>
llvm-svn: 201830
Somehow both Daniel and I missed the fact that while loops are only identical
if they have identical bodies.
Patch by Daniel Fahlgren!
llvm-svn: 201829
The pp-trace clang tool was using it successfully. We can still delete
the callbacks in Frontend/PrintPreprocessedOutput.cpp because they were
effectively dead.
llvm-svn: 201825
The MS ABI requires that we determine the vbptr offset if have a
virtual inheritance model. Instead, raise an error pointing to the
diagnostic when this happens.
This fixes PR18583.
Differential Revision: http://llvm-reviews.chandlerc.com/D2842
llvm-svn: 201824
This reverts commit r201810.
It was failing these tests on my workstation:
Clang :: CodeGen/override-layout.c
Clang :: CodeGenCXX/override-layout.cpp
Clang :: PCH/check-deserializations.cpp
llvm-svn: 201823
gcc never expands macros in pragmas and MSVC always expands macros
before processing pragmas. Clang usually allows macro expansion, except
in a handful of pragmas, most of which are handled by the lexer.
Also remove PPCallbacks for pragmas that are currently handled in the
parser. Without a Parser, such as with clang -E, these callbacks would
never be called.
Fixes PR18576.
llvm-svn: 201821
This reduces the number of files we need to touch to add a new pragma,
and reduces the number of externally visible symbols in clang.
Make the handlers structs instead of classes because the vast majority
have no private members.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2834
llvm-svn: 201820
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
llvm-svn: 201818
External sources shouldn't prevent the layout engine from using
MSLayout. If lldb were to support debugging in microsoft mode, some
code will need to be added to MSRecordLayoutBuilder to handel external
layouts.
llvm-svn: 201810
hasAnyTemplateArgument, and (out of necessity) an isExpr matcher.
Also updates the TemplateArgument doxygen to reflect reality for
non-canonical template arguments.
Differential Revision: http://llvm-reviews.chandlerc.com/D2810
llvm-svn: 201804
Summary:
This removes the need to coerce UnknownABI to the default ABI (O32 for
MIPS32, N64 for MIPS64 [*]) in both MipsSubtarget and MipsAsmParser.
Clang has been updated to disable both possible default ABI's before enabling
the ABI it intends to use.
[*] N64 being the default for MIPS64 is not actually correct.
However N32 is not fully implemented/tested yet.
Depends on: D2830
Reviewers: jacksprat, matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D2832
Differential Revision: http://llvm-reviews.chandlerc.com/D2846
llvm-svn: 201792
This breaks backwards compatibility with existing code. Previously, this
was defined as
#define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0, (sel)))
Which basically accepts any pointer. Changing this to char* simply
breaks a lot of existing code. I have tried changing char* to
"const void*", which seems to be the right thing as per Intel
specification this should work on basically any pointer. However,
apparently this breaks windows compatibility (because of a conflicting
declaration in windows.h).
So, we probably need to #ifdef this based on whether clang is compiling
for windows. According to Chandler, this might be done by introducing an
additional symbol to a fake type in BuiltinsX86.def and then condition
the type expansion on the platform.
llvm-svn: 201775
This patch adds several built-ins that are required for ms
compatibility. _mm_prefetch must be a built-in because it takes a
compile-time constant argument and our prior approach of using a #define
to the current built-in doesn't work in the presence of re-declaration
of _mm_prefetch. The others can be obtained by including the windows
system headers. If a user includes the windows system headers but not
intrin.h they still need to work and therefore must be built-in because
we don't get a chance to implement them in intrin.h in this case.
llvm-svn: 201734
This definition is not chosen idly. There is an unfortunate reality with
max_align_t -- the specific nature of its definition leaks into the ABI
almost immediately. Because it is part of C11 and C++11 it becomes
essential for it to match with other systems on that ABI. There is an
effort to discourage any further use of this construct as a consequence
-- using max_align_t introduces an immediate ABI problem. We can never
update it to have larger alignment even as the microarchitecture changes
to necessitate higher alignment. =/
The particular definition here exactly matches the ABI of GCC's chosen
::max_align_t definition, for better or worse. This was written with the
help of Richard Smith who was decoding the exact ABI implications of the
selected definition in GCC. Notably, in-register arguments are impacted
by the particular definition chosen. =/
No one is under the illusion that this is a "good" or "useful"
definition of max_align_t, and we are working with the standards
committee to specify a more useful interface to address this need.
llvm-svn: 201729
In the Microsoft ABI, the vftable is laid out as if all methods in every
overload set were declared in reverse order of declaration at the point
of declaration of the first overload in the set.
Previously we only considered virtual methods in an overload set, but
MSVC includes non-virtual methods for ordering purposes.
Fixes PR18902.
llvm-svn: 201722
IdenticalExprChecker now warns if any expressions in a logical or bitwise
chain (&&, ||, &, |, or ^) are the same. Unlike the previous patch, this
actually checks all subexpressions against each other (an O(N^2) operation,
but N is likely to be small).
Patch by Daniel Fahlgren!
llvm-svn: 201702
This extends the checks for identical expressions to handle identical
statements, and compares the consequent and alternative ("then" and "else")
branches of an if-statement to see if they are identical, treating a single
statement surrounded by braces as equivalent to one without braces.
This does /not/ check subsequent branches in an if/else chain, let alone
branches that are not consecutive. This may improve in a future patch, but
it would certainly take more work.
Patch by Daniel Fahlgren!
llvm-svn: 201701
This fixes one immediate bug where an expression with side-effects
could be emitted twice during a NEON call.
It also prepares the way for folding CodeGen for many of the SISD
intrinsics into a table, reducing code size and hopefully increasing
performance eventually ("binary search + few switch cases" should be
better than "lots of switch cases").
llvm-svn: 201667
These instructions (well, the f32 ones) are supported on 32-bit ARMv8, not just
AArch64. Now that the arm_neon.td refactoring is complete, adding them is
surprisingly simple.
rdar://problem/16035743
llvm-svn: 201661
There are two kinds of automatically generated tests for NEON intrinsics, both
of which can be merged without adversely affecting users.
1. We check that a valid kind of __builtin_neon_XYZ overload is requested (e.g.
we're not asking for a float32x4_t version when it only accepts integers. Since
the __builtin_neon_XYZ intrinsics should only be used in arm_neon.h, relaxing
this test and permitting AArch64 types for AArch32 should not cause a problem.
The extra arm_neon.h definitions should be #ifdefed out anyway.
2. We check that intrinsics which take immediates are actually given
compile-time constants within range. Since all NEON intrinsics should be
backwards compatible, these tests should be identical on AArch64 and AArch32
anyway.
This patch, therefore, merges the separate AArch64 and 32-bit checks.
rdar://problem/16035743
llvm-svn: 201659
DR18 previously forebode typedefs to be used as parameter types if they
were of type 'void'. DR577 allows 'void' to be used as a function
parameter type regardless from where it came.
llvm-svn: 201631
This makes Clang and LLVM -Wmsvc-include clean.
I believe the correct behavior here is to avoid updating the cache when
we find the header via MSVC's search rules.
Differential Revision: http://llvm-reviews.chandlerc.com/D2733
llvm-svn: 201615
Summary:
Generally the vector deleting dtor, which we model as a vtable thunk,
takes care of non-virtual adjustment and delegates to the other
destructor variants. The other non-complete destructor variants assume
that 'this' on entry points to the virtual base subobject that first
declared the virtual destructor.
We need to change the adjustment in both the prologue and the vdtor call
setup.
Reviewers: timurrrr
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2821
llvm-svn: 201612
This warning has a whole bunch of known false positives, much of them due
to code that is "sometimes unreachable". This can caused by code that
is conditionally generated by the preprocessor, branches that are defined
in terms of architecture-specific details (e.g., the size of a type), and
so on. While these are all good things to address one by one, the reality
is that this warning has received little love lately. By restricting
its purvue, we can focus on the top issues effecting main files, which
should be smaller, and then gradually widen the scope.
llvm-svn: 201607
The following attributes have been (silently) deprecated, with their replacements listed:
lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability
There are no functional changes intended.
llvm-svn: 201585
Extended qualifiers can appear in many places, refactor the code so it's
more reusable. Add tests in areas where we've increased compatibility.
llvm-svn: 201574
Pointer types in the MSVC ABI are a bit awkward, the width of the
pointer is considered a kind of CVR qualifier.
Restrict is handled similarly to const and volatile but is mangled after
the pointer width qualifier.
This fixes PR18880.
llvm-svn: 201569
temporary in a decltype expression only applies if that temporary was created
by a function call, not by a function-style cast or other flavour of
expression.
llvm-svn: 201542
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
This implements FIXME from Checker.cpp (FIXME: We want to return the package + name of the checker here.) and replaces hardcoded checker names with the new ones obtained via getCheckName().getName().
llvm-svn: 201525
Generally people seem to prefer wrapping the first function parameter
over wrapping the trailing tokens "const", "override" and "final". This
does not extend to function-like annotations and probably not to other
non-standard annotations.
Before:
void someLongFunction(int SomeLongParameter)
const { ... }
After:
void someLongFunction(
int SomeLongParameter) const { ... }
llvm-svn: 201504
When a function has a single counter, we will offset the pointer by 1 when
parsing the next function. If a function has multiple counters, we are
okay after skipping rest of the counters.
llvm-svn: 201456
properties by fixing shouldBindAsLValue to accept arrays
(like record types) because we always manipulate
them in memory. Patch suggested by John MaCall.
// rdar://15610943
llvm-svn: 201428
continue header lookup using the framework include as filename.
This allows us to conveniently treat
#import "Foo.h"
as an implicit module import if we can resolve "Foo/Foo.h" as such.
rdar://16042979
llvm-svn: 201419
and the class name is shadowed by another member. Recovery still needs
to be figured out, which is non-trivial since the parser has already gone
down a much different path than if it had recognized the class template
as type instead of seeing the member that shadowed the class template.
llvm-svn: 201360
This changes ARM to use @llvm.fabs for floating-point vabs. Patterns
already existed in the backend, and it might help mid-end phases since
it's more likely to be understood than @llvm.arm.neon.vabs.
llvm-svn: 201313
This commit is not strictly correct nor accounts for all uses (shared
objects, for example), but it allows one to test the compiler-rt library
on GNU targets.
Using this patch to run the test-suite has already shown me problems
on ARM. Since this is a Darwin-only flag, nobody is using it, so it
shouldn't be a problem.
I will need extension to deal with the shared cases, but since we're
not compiling libclang_rt.so, that's not yet applicable. Many other
problems will have to be fixed first in compiler-rt (such as removing
the 'arch' name from it and making it trully multi-arch, moving it to
the default lib directory, make both .a and .so variants, etc).
llvm-svn: 201307
According to the GNU docs, zero-sized bitfields should not be affected by the
packed attribute.
Differential Revision: http://llvm-reviews.chandlerc.com/D2693
llvm-svn: 201288
useBitFieldTypeAlignment() and appears to ignore the special
bit-packing semantics of __attribute__((packed)).
Further flesh out an already-extensive comment.
llvm-svn: 201282
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
llvm-svn: 201274
Previously, range checking on the __builtin_neon_XYZ_v Clang intrinsics didn't
take account of the type actually passed to the call, which meant a request
like "vext_s16(a, b, 7)" was allowed through (TableGen was conservative and
allowed 0-7 for all types). This caused an assert in the backend because the
lane doesn't make sense.
llvm-svn: 201232
the build
When Clang loads the module, it verifies the user source files that the module
was built from. If any file was changed, the module is rebuilt. There are two
problems with this:
1. correctness: we don't verify system files (there are too many of them, and
stat'ing all of them would take a lot of time);
2. performance: the same module file is verified again and again during a
single build.
This change allows the build system to optimize source file verification. The
idea is based on the fact that while the project is being built, the source
files don't change. This allows us to verify the module only once during a
single build session. The build system passes a flag,
-fbuild-session-timestamp=, to inform Clang of the time when the build started.
The build system also requests to enable this feature by passing
-fmodules-validate-once-per-build-session. If these flags are not passed, the
behavior is not changed. When Clang verifies the module the first time, it
writes out a timestamp file. Then, when Clang loads the module the second
time, it finds a timestamp file, so it can compare the verification timestamp
of the module with the time when the build started. If the verification
timestamp is too old, the module is verified again, and the timestamp file is
updated.
llvm-svn: 201224
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
This reverts r201203 (i.e. re-applying r201202 with small fixes in
unittests/CMakeLists.txtto make the build bots happy).
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201205
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201202
vptr injection must inject padding equivalent to the alignment of the
most aligned non-virtual subobject, not the alignment of the enclosing
record.
To fascilitate this change, don't let record layout observe the
alignment of the record until we've injected our vptrs. Also, do not
allow the alignment of vbases to affect required alignment until just
before we insert the vtordisp field.
llvm-svn: 201199
Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.
This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.
Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.
Reviewers: jordan_rose, krememek
Reviewed By: jordan_rose
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2557
llvm-svn: 201186
These flags control the inheritance model initially used by the
translation unit.
Differential Revision: http://llvm-reviews.chandlerc.com/D2741
llvm-svn: 201175
It is actually useful to warn in such cases, thanks to Dmitri for pushing on this and making us see the light!
Related to rdar://15925483 and rdar://15922612. The latter radar is where the usefulness of the warning is most clear.
llvm-svn: 201165
Thanks to r199467, __attribute__((nonnull)) (without arguments) can apply
directly to parameters, instead of being applied to the whole function.
However, the old form of nonnull (with an argument index) could also apply
to the arguments of function and block pointers, and both of these can be
passed as parameters.
Now, if 'nonnull' with an argument is found on a parameter, /and/ the
parameter is a function or block pointer, it is handled the old way.
PR18795
llvm-svn: 201162
The s64/u64 vcvt conversion operations are actually pretty much identical to
the s32/u32 ones in implementation, and can be shared with just one extra
variable.
llvm-svn: 201145
Xcore target ABI requires const data that is externally visible
to be handled differently if it has C-language linkage rather than
C++ language linkage.
llvm-svn: 201142
Before:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
After:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
llvm-svn: 201138
According to the AAPCS, we can split structs between GPRs and the stack,
except for when an argument has already been allocated on the stack. This
can occur when a large number of floating-point arguments fill up the VFP
registers, and are alllocated on the stack before the general-purpose argument
registers are full.
llvm-svn: 201137
This triggered a miscompilation of code using Boost's function_template.hpp
when it was included inside a PCH file. A local static within
that header would be treated as local extern, resulting in the wrong
mangling. This only occurred during PCH deserialization.
Fixes <rdar://problem/15975816> and <rdar://problem/15926311>.
llvm-svn: 201130
This will let us stage in the modeling of operator new. The -analyzer-config
opton 'c++-inline-allocators' is currently off by default.
Patch by Karthik Bhat!
llvm-svn: 201122
This option has the following effects:
* It adds the sspstrong IR attribute to each function within the CU.
* It defines the macro __SSP_STRONG__ with the value of 2.
Differential Revision: http://llvm-reviews.chandlerc.com/D2717
llvm-svn: 201120
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
llvm-svn: 201105
Now that both ARM backends use the same implementation for vshll operations,
the code can be shared. This is also a necessary LLVM/Clang interface update.
llvm-svn: 201094
Now the backend supports the natural LLVM IR, we can shamelessly steal the
AArch64 front-end code to implement the vshrn intrinsic on 32-bit ARM.
llvm-svn: 201086
Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)
Included a few FIXMEs in tests where some further improvements could be
made.
llvm-svn: 201038
TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).
Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSuitableAlign() so
that libc++ may take advantage of it.
llvm-svn: 201037
template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.
llvm-svn: 201031
unique them and permits the implementation of dynamic_cast (and
anything else which knows it's working with a complete class
type) to compare their addresses directly.
rdar://16005328
llvm-svn: 201020
Summary:
This avoids false positives from -Wmicrosoft when name lookup would
normally succeed in standard C++. This triggered on a common CRTP
pattern in clang, where a derived class would have a private using decl
to pull in members of a dependent base:
class Verifier : InstVisitor<Verifier> {
private:
using InstVisitor<Verifier>::visit;
...
void anything() {
visit(); // warned here
}
};
Real access checks pass here because we're in the context of the
Verifier, but the -Wmicrosoft extension was just looking for the private
access specifier.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2679
llvm-svn: 201019
'operator delete' or 'operator delete[]' is an explicit exception
specification. Therefore we should diagnose 'void operator delete(void*)'
instead of 'void operator delete(void*) noexcept'.
This diagnostic remains an ExtWarn, since in practice people don't always
include the exception specification in such a declaration.
llvm-svn: 201002
This means always walking the whole call stack for the end path node, but
we'll assume that's always fairly tractable.
<rdar://problem/15952973>
llvm-svn: 200980
We don't stat the system headers to check for stalenes during regular
PCH loading for performance reasons. When explicitly saying
-verify-pch, we want to check all the dependencies - user or system.
llvm-svn: 200979
An HFA is defined as a struct containing floating point values of the
same machine type. In the 32-bit ABI, double and long double have the
same machine type, so a struct with a mixture of these types must be an
HFA (assuming it meets the other criteria).
llvm-svn: 200971
hack of passing -fconst-strings to -cc1"
Passing or not a language option based on diagnostic settings is a bad idea, it breaks
using a PCH that was compiled with different diagnostic settings.
Also add a test case to make sure we don't regress.
llvm-svn: 200964
If we are in the middle of defining the class, don't attempt to
validate previously annotated declarations. We may not have seen base
specifiers or virtual method declarations yet.
llvm-svn: 200959
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-dependent subexpressions, for
instance.
We should really give ParenListExprs (and InitListExprs) the type of the
initialized entity if they're used to represent a dependent initialization (and
if so, set them to be type-, value- and instantiation-dependent).
llvm-svn: 200954
Use the verify hook rather than the compile hook to represent the
-verify-pch action, and move the exising --verify-debug-info action
into its own subclass of VerifyJobAction. Incidentally change the name
printed by -ccc-print-phases for --verify-debug-info.
llvm-svn: 200938
Properly support fields that come from anonymous unions and structs
when used as template arguments for pointer to data member params.
llvm-svn: 200921
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
In the following code:
struct A { static const int sz; };
template<class T> void f() { T arr[A::sz]; }
the array 'arr' is represented as a variable size array in the template.
If 'A::sz' gets value below in the translation unit, the array in
instantiation can turn into constant size array.
This change fixes PR18633.
Differential Revision: http://llvm-reviews.chandlerc.com/D2688
llvm-svn: 200899
using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
This option will:
- load the given pch file
- verify it is not out of date by stat'ing dependencies, and
- return 0 on success and non-zero on error
llvm-svn: 200884
We collect a maximal function count among all functions in the pgo data file.
For functions that are hot, we set its InlineHint attribute. For functions that
are cold, we set its Cold attribute.
We currently treat functions with >= 30% of the maximal function count as hot
and functions with <= 1% of the maximal function count are treated as cold.
These two numbers are from preliminary tuning on SPEC.
This commit should not affect non-PGO builds and should boost performance on
instrumentation based PGO.
llvm-svn: 200874
Function references always use $1? like function pointers and never $E?
like var decl references. Static methods are mangled like function
pointers.
llvm-svn: 200869
Because in C++, "anonymous" doesn't mean "nameless" for records. In
other words, RecordDecl::isAnonymousStructOrUnion only returns true if
the record lacks a name *and* is not used as the type in an object's
declaration.
llvm-svn: 200868
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
It seems like most people see unary operators more like part of the
subsequent identifier and find relative indentation odd.
Before:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
After:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
llvm-svn: 200840
We accept these with a warning in MS mode, but we would previously mark them
invalid, causing us not to emit code for them.
Differential Revision: http://llvm-reviews.chandlerc.com/D2681
llvm-svn: 200815
When a lax conversion featured a vector and a non-vector, we were
only requiring the non-vector to be a scalar type, but really it
needs to be a real type (i.e. integral or real floating); it is
not reasonable to allow a pointer, member pointer, or complex
type here.
r198474 required lax conversions to match in "data size", i.e.
element size * element count, forbidding matches that happen
only because a vector is rounded up to the nearest power of two
in size. Unfortunately, the erroneous logic was repeated in
several different places; unify them to use the new condition,
so that it triggers for arbitrary conversions and not just
those performed as part of binary operator checking.
rdar://15931426
llvm-svn: 200810
In TokenLexer::ExpandFunctionArguments(), CurTok.hasLeadingSpace() is
checked in multiple locations, each time subtly differently. Checking it
early, when the token is seen, and using NextTokGetsSpace exclusively
after that makes the code simpler.
No change in behaviour is intended.
Patch by Harald van Dijk!
llvm-svn: 200788
When a macro expansion does not result in any tokens, and the macro name
is preceded by whitespace, the whitespace should be passed to the first
token that follows the macro expansion. Similarly when a macro expansion
ends with a placemarker token, and that placemarker token is preceded by
whitespace. This worked already for top-level macro expansions, but is
now extended to also work for nested macro expansions.
Patch by Harald van Dijk!
llvm-svn: 200787
When a function-like macro definition ends with one of the macro's
parameters, and the argument is empty, any whitespace before the
parameter name in the macro definition needs to be preserved. Promoting
the existing NextTokGetsSpace to a preserved bit-field and checking it
at the end of the macro expansion allows it to be moved to the first
token following the macro expansion result.
Patch by Harald van Dijk!
llvm-svn: 200786
In x ## y, where x and y are regular tokens, whitespace between x and ##
is ignored, and whitespace between ## and y is also ignored. When either
x or y is a function argument, whitespace was preserved, but it should
not be. This patch removes the checks for whitespace before ## and
before y, and in the special case where x is an empty macro argument and
y is a regular token, actively removes whitespace before y.
One existing test is affected by that change, but as clang's output now
matches the standard's requirements and that of GCC, I've tweaked the
testcase.
Patch by Harald van Dijk!
llvm-svn: 200785
Now that the back-end intrinsics are more regular, there's no need for the
special handling these got in the front-end, so they can be moved to
EmitCommonNeonBuiltinExpr.
llvm-svn: 200769
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
David Majnemer