Commit Graph

3673 Commits

Author SHA1 Message Date
Aditya Kumar b906230bcb Keep the test only for Itanium abi
llvm-svn: 283085
2016-10-03 02:36:33 +00:00
Aditya Kumar e84372b039 Alias must point to a definition
Reapplying the patch after modifying the test case.

Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341

This patch disables alias to available_externally definitions.

Reviewers: eugenis, rsmith

Differential Revision: https://reviews.llvm.org/D24682

llvm-svn: 283063
2016-10-02 03:06:36 +00:00
Saleem Abdulrasool 8dbaf5cb4d CodeGen: inherit DLLExport attribute in Windows Itanium
When emitting the fundamental type information constants, inherit the
DLLExportAttr from `__fundamental_type_info`.  We would previously not
honor the `__declspec(dllexport)` on the type information.

llvm-svn: 282980
2016-09-30 23:11:05 +00:00
Richard Smith a560ccf2af Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.

We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.

Approach reviewed off-line by rnk.

llvm-svn: 282777
2016-09-29 21:30:12 +00:00
Aditya Kumar 09a8c7d489 Revert "[PR30341] Alias must point to a definition"
This reverts commit r282679.

Ninja check fails, reverting to debug the issue.

llvm-svn: 282710
2016-09-29 11:37:23 +00:00
Aditya Kumar 13a18fecdd [PR30341] Alias must point to a definition
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341

This patch disables alias to available_externally definitions.

Reviewers: eugenis, rsmith

Differential Revision: https://reviews.llvm.org/D24682

llvm-svn: 282679
2016-09-29 03:32:04 +00:00
Richard Smith 762672a73a Re-commit r282556, reverted in r282564, with a fix to CallArgList::addFrom to
function correctly when targeting MS ABIs (this appears to have never mattered
prior to this change).

Update test case to always cover both 32-bit and 64-bit Windows ABIs, since
they behave somewhat differently from each other here.

Update test case to also cover operators , && and ||, which it appears are also
affected by P0145R3 (they're not explicitly called out by the design document,
but this is the emergent behavior of the existing wording).


Original commit message:

P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)

This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).

llvm-svn: 282619
2016-09-28 19:09:10 +00:00
Richard Smith 4499145a5f Revert r282556. This change made several bots unhappy.
llvm-svn: 282564
2016-09-28 02:20:06 +00:00
Richard Smith 97a616d624 P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)

This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).

llvm-svn: 282556
2016-09-27 23:44:22 +00:00
Richard Smith 689bb78631 Defend test against differences between 32-bit and 64-bit MSABI manglings.
llvm-svn: 282463
2016-09-27 00:52:29 +00:00
Richard Smith bde62d78e9 P0145R3 (C++17 evaluation order tweaks): evaluate the base expression before
the pointer-to-member expression in calls through .* and ->* expressions.

llvm-svn: 282457
2016-09-26 23:56:57 +00:00
Richard Smith 9e67b9922b P0145R3 (C++17 evaluation order tweaks): consistently emit the LHS of array
subscripting before the RHS, regardless of which is the base and which is the
index.

llvm-svn: 282453
2016-09-26 23:49:47 +00:00
Dmitry Polukhin fda467b252 PR30401: Fix substitutions for functions with abi_tag
llvm-svn: 282059
2016-09-21 08:27:03 +00:00
Richard Smith d8e3ac3185 Fix a couple of wrong-code bugs in switch-on-constant optimization:
* recurse through intermediate LabelStmts and AttributedStmts when checking
   whether a statement inside a switch declares a variable
 * if the end of a compound statement is reachable from the chosen case label,
   and the compound statement contains a variable declaration, it's not valid
   to just emit the contents of the compound statement -- we must emit the
   statement itself or we lose the scope (and thus end lifetimes at the wrong
   point)

llvm-svn: 281797
2016-09-16 23:30:39 +00:00
John McCall d23b27e0d8 Alter the iOS/tvOS ARM64 C++ ABI to ignore the upper half of the
virtual table offset in a member function pointer.

We are reserving this space for future ABI use relating to alternative
v-table configurations.  In the meantime, continue to zero-initialize
this space when actually emitting a member pointer literal.

This will successfully interoperate with existing compilers.
Future versions of the compiler may place additional data in
this location, and at that point, code emitted by compilers
prior to this patch will fail if exposed to such a member pointer.
This is therefore a somewhat hard ABI break.  However, because
it is limited to an uncommon case of an uncommon language feature,
and especially because interoperation with the standard library
does not depend on member pointers, we believe that with a
sufficiently advance compiler change the impact of this break
will be minimal in practice.

llvm-svn: 281693
2016-09-16 02:40:45 +00:00
Wei Mi 6582669aa9 Update clang unittests for rL281586.
The change in rL281586 is in llvm component and tests updated here are
in clang component, so I have to commit them consecutively.

llvm-svn: 281587
2016-09-15 06:31:30 +00:00
Hans Wennborg 1b3aee7ff9 Also don't inline dllimport functions referring to non-dllimport constructors.
The AST walker wasn't visiting CXXConstructExprs before.

This is a follow-up to r281395.

llvm-svn: 281413
2016-09-13 22:51:42 +00:00
Akira Hatanaka 255abad9b1 [CodeGen] Fix an assert in EmitNullConstant.
r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual
bases of size 0, which prevented adding those non-virtual bases to
CGRecordLayout's NonVirtualBases. This caused clang to assert when
CGRecordLayout::getNonVirtualBaseLLVMFieldNo was called in
EmitNullConstant. This commit fixes the bug by ignoring zero-sized
non-virtual bases in EmitNullConstant.

rdar://problem/28100139

Differential Revision: https://reviews.llvm.org/D24312

llvm-svn: 281405
2016-09-13 22:13:02 +00:00
Hans Wennborg 93f7547260 Try harder to not inline dllimport functions referencing non-dllimport functions
In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations because those are not reflected
in the AST. This adds a separate check for them.

llvm-svn: 281395
2016-09-13 21:08:20 +00:00
Peter Collingbourne eeb56abe64 Update Clang for D20147 ("DebugInfo: New metadata representation for global variables.")
Differential Revision: http://reviews.llvm.org/D20415

llvm-svn: 281285
2016-09-13 01:13:19 +00:00
Reid Kleckner 6c7b1c6212 [DebugInfo] Deduplicate debug info limiting logic
We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.

Also reduce a test case for this slightly.

Implementing review feedback from David Blaikie on r281057.

llvm-svn: 281278
2016-09-13 00:01:23 +00:00
David Majnemer cb60a4305b [MS ABI] Add /include directives for dynamic TLS
MSVC emits /include directives in the .drective section for the
__dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit).

This fixes PR30347.

llvm-svn: 281189
2016-09-12 02:51:43 +00:00
Reid Kleckner 22466a92e1 [DebugInfo] Ensure complete type is emitted with -fstandalone-debug
The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.

llvm-svn: 281057
2016-09-09 17:03:53 +00:00
Reid Kleckner c9404e1039 [codeview] Extend the heuristic for detecting classes imported from DLLs
If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.

This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.

llvm-svn: 281053
2016-09-09 16:27:04 +00:00
Richard Smith 8df390f9eb C++ Modules TS: Add parsing and some semantic analysis support for
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.

llvm-svn: 280999
2016-09-08 23:14:54 +00:00
Ismail Pazarbasi 4a00774e59 Try contextually converting condition of constexpr if to Boolean value
Summary:
C++1z 6.4.1/p2:
 If the if statement is of the form if constexpr, the value of the
 condition shall be a contextually converted constant expression of type
 bool [...]
C++1z 5.20/p4:
 [...] A contextually converted constant expression of type bool is an
 expression, contextually converted to bool (Clause4), where the
 converted expression is a constant expression and the conversion
 sequence contains only the conversions above. [...]

Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.

An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.

Also, fixes PR28470.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D24158

llvm-svn: 280838
2016-09-07 18:24:54 +00:00
Reid Kleckner e5a321b5e8 [MS] Fix prologue this adjustment when 'this' is passed indirectly
Move the logic for doing this from the ABI argument lowering into
EmitParmDecl, which runs for all parameters. Our codegen is slightly
suboptimal in this case, as we may leave behind a dead store after
optimization, but it's 32-bit inalloca, and this fixes the bug in a
robust way.

Fixes PR30293

llvm-svn: 280836
2016-09-07 18:21:30 +00:00
Reid Kleckner 034e727001 [MS] Fix 'this' type when calling virtual methods with inalloca
If the virtual method comes from a secondary vtable, then the type of
the 'this' parameter should be i8*, and not a pointer to the complete
class. In the MS ABI, the 'this' parameter on entry points to the vptr
containing the virtual method that was called, so we use i8* instead of
the normal type. We had a mismatch where the CGFunctionInfo of the call
didn't match the CGFunctionInfo of the declaration, and this resulted in
some assertions, but now both sides agree the type of 'this' is i8*.

Fixes one issue raised in PR30293

llvm-svn: 280815
2016-09-07 15:15:51 +00:00
Richard Smith 7c2bcc9eb0 Fix clang's handling of the copy performed in the second phase of class
copy-initialization. We previously got this wrong in a couple of ways:
 - we only looked for copy / move constructors and constructor templates for
   this copy, and thus would fail to copy in cases where doing so should use
   some other constructor (but see core issue 670),
 - we mishandled the special case for disabling user-defined conversions that
   blocks infinite recursion through repeated application of a copy constructor
   (applying it in slightly too many cases) -- though as far as I can tell,
   this does not ever actually affect the result of overload resolution, and
 - we misapplied the special-case rules for constructors taking a parameter
   whose type is a (reference to) the same class type by incorrectly assuming
   that only happens for copy/move constructors (it also happens for
   constructors instantiated from templates and those inherited from base
   classes).

These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.

llvm-svn: 280776
2016-09-07 02:14:33 +00:00
Nico Weber 05e1dadac6 [ms] Add support for parsing uuid as a Microsoft attribute.
Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:

  [uuid("....")] class IBufferByteAccess {};

To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it.  Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.

Final part of https://reviews.llvm.org/D23895

llvm-svn: 280578
2016-09-03 03:25:22 +00:00
Yunzhong Gao f4903a3675 (clang part) Implement MASM-flavor intel syntax behavior for inline MS asm block.
Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.     
   0xNN and NNh may come with optional U or L suffix.                            
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.           
   NNb may come with optional U or L suffix.                                     
                                                                                 
Differential Revision: https://reviews.llvm.org/D22112

llvm-svn: 280556
2016-09-02 23:16:06 +00:00
Reid Kleckner 598124296b [codeview] Don't emit vshape info for classes without vfptrs
Classes with no virtual methods or whose virtual methods were all
inherited from virtual bases don't have a vfptr at offset zero. We were
crashing attempting to get the layout of that non-existent vftable.

We don't need any vshape info in this case because the debugger can
infer it from the base class information. The current class may not
introduce any virtual methods if we are in this situation.

llvm-svn: 280287
2016-08-31 20:35:01 +00:00
Reid Kleckner dc124996d2 [codeview] Pass through vftable shape information
The shape is really just the number of methods in the vftable, since we
don't support 16 bit far calls. All calls are near. Encode this number
in the size of the artificial __vtbl_ptr_type DIDerivedType that we
generate. For DWARF, this will be a normal pointer, but for codeview
this will be a wide pointer that gets pattern matched into a
VFTableShape record. Insert this type into the element list of all
dynamic classes when emitting CodeView, so that the backend can emit the
shape even if the vptr lives in a primary base class.

Fixes PR28150

llvm-svn: 280255
2016-08-31 16:11:43 +00:00
Reid Kleckner d8b0466e19 Widen type of __offset_flags in RTTI on Mingw64
Otherwise we can't handle secondary base classes at offsets greater than
2**24. This agrees with libstdc++abi.

We could extend this change to other LLP64 platforms, but then we would
want to update libc++abi and it would require additional review.

Fixes PR29116

llvm-svn: 279786
2016-08-25 22:16:30 +00:00
Reid Kleckner 44051e63de [MS] Pass non-trivially-copyable objects indirectly on Windows ARM
This isn't exactly what MSVC does, unfortunately. MSVC does not pass
objects with destructors but no copy constructors by address. More ARM
expertise is required to really understand what should be done here.

Fixes PR29136.

llvm-svn: 279764
2016-08-25 18:23:28 +00:00
Adam Nemet 9c84859075 [Pragma] Clear loop distribution attribute between loops
llvm-svn: 279608
2016-08-24 04:31:56 +00:00
David Blaikie 87173f108a PR29086: DebugInfo: Improve support for fixed array dimensions in variable length arrays
llvm-svn: 279445
2016-08-22 17:49:56 +00:00
David Blaikie c41fcaf8aa Remove redundant test
test/CodeGenCXX/debug-info-zero-length-arrays.cpp tests this
functionality more comprehensively

llvm-svn: 279444
2016-08-22 17:49:50 +00:00
Adrian McCarthy 992429843b Emit debug info for dynamic classes if they are imported from a DLL.
With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger.

The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows.

Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc.

llvm-svn: 278861
2016-08-16 22:11:18 +00:00
Richard Smith 39a7c4c65a Add a triple to this test to make buildbots happier.
llvm-svn: 278647
2016-08-15 02:24:00 +00:00
Richard Smith da38363784 P0217R3: code generation support for decomposition declarations.
llvm-svn: 278642
2016-08-15 01:33:41 +00:00
David Blaikie 2a58a18d67 PR26423: Assert on valid use of using declaration of a function with an undeduced auto return type
For now just disregard the using declaration in this case. Suboptimal,
but wiring up the ability to have declarations of functions that are
separate from their definition (we currently only do that for member
functions) and have differing return types (we don't have any support
for that) is more work than seems reasonable to at least fix this crash.

llvm-svn: 277852
2016-08-05 19:03:01 +00:00
Reid Kleckner 755220bcef [codeview] Skip injected class names in nested record emission
We were already trying to do this, but our check wasn't quite right.

Fixes PR28790

llvm-svn: 277367
2016-08-01 18:56:13 +00:00
Reid Kleckner 939119dcb2 Fix naked.cpp test on 32-bit Windows
llvm-svn: 277205
2016-07-29 19:43:28 +00:00
Justin Lebar ed4f172c00 Don't crash when generating code for __attribute__((naked)) member functions.
Summary:
Previously this crashed inside EmitThisParam().  There should be no
prelude for naked functions, so just skip the whole thing.

Reviewers: majnemer

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D22715

llvm-svn: 276925
2016-07-27 22:04:24 +00:00
David Majnemer 0ed275c773 Update test to account for r276604
llvm-svn: 276607
2016-07-25 04:47:45 +00:00
Anna Thomas 142ea99832 Clang changes for overloading invariant.start and end intrinsics
This change depends on the corresponding LLVM change at:
https://reviews.llvm.org/D22519

The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address
space.

With this LLVM change, these intrinsics are overloaded for any adddress space
for memory objects and we can use these llvm invariant intrinsics in
non-default address spaces.

Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)

This overloaded intrinsic is needed for representing final or invariant
memory in managed languages.

llvm-svn: 276448
2016-07-22 17:50:08 +00:00
Erik Pilkington 1ac8adfcab [CodeGen] Fix a crash when constant folding switch statement
Differential revision: https://reviews.llvm.org/D22542

llvm-svn: 276350
2016-07-21 22:31:40 +00:00
Adrian McCarthy ab1e786503 Reroll "Include unreferenced nested types in member list only for CodeView"
Another attempt at r276271, hopefully without breaking ModuleDebugInfo test.

llvm-svn: 276317
2016-07-21 18:43:20 +00:00
Adrian McCarthy a9a89ae77f Revert "Include unreferenced nested types in member list only for CodeView"
Patch broke ModuleDebugInfo test on the build bots (but not locally).  Again.

svn revision:  r276271

This reverts commit 9da8a1b05362bc96f2855fb32b5588b89407685d.

llvm-svn: 276279
2016-07-21 13:41:25 +00:00