Commit Graph

4122 Commits

Author SHA1 Message Date
Piotr Padlewski 5dde809404 Rename invariant.group.barrier to launder.invariant.group
Summary:
This is one of the initial commit of "RFC: Devirtualization v2" proposal:
https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing

Reviewers: rsmith, amharc, kuhar, sanjoy

Subscribers: arsenm, nhaehnle, javed.absar, hiraditya, llvm-commits

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

llvm-svn: 331448
2018-05-03 11:03:01 +00:00
Richard Smith 32ac816fff Fix bogus MSVC char8_t mangling.
This appears to have been caused by a bad automatic svn merge with r330225
attaching the 'case' label to the wrong block of code. :(

llvm-svn: 331299
2018-05-01 18:50:15 +00:00
Chandler Carruth abb22405e6 Fix up r331244 - the emitted definition is weak_odr linkage. Should get
the build bots to healthy again without a full revert. As the
functionality added has nothing to do with linkage this seems unlikely
to represent a deep or interesting bug in the patch.

llvm-svn: 331245
2018-05-01 06:48:30 +00:00
Richard Smith 3a8244df6f Implement P0482R2, support for char8_t type.
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)

This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.

llvm-svn: 331244
2018-05-01 05:02:45 +00:00
Richard Smith 4ae767ba3d PR37275 packed attribute should not apply to base classes
Clang incorrectly applied the packed attribute to base classes. Per GCC's
documentation and as can be observed from its behavior, packed only applies to
members, not base classes.

This change is conditioned behind -fclang-abi-compat so that an ABI break can
be avoided by users if desired.

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

llvm-svn: 331136
2018-04-29 04:55:46 +00:00
Erik Pilkington e7e8772446 [ItaniumMangle] Undeduced auto type shouldn't be substitutable.
We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.

Differential revision: https://reviews.llvm.org/D45451

llvm-svn: 331098
2018-04-28 02:40:28 +00:00
Akira Hatanaka ccda3d2970 [CodeGen] Avoid destructing a callee-destructued struct type in a
function if a function delegates to another function.

Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.

This reapplies r331016, which was reverted in r331019 because it caused
an assertion to fail in EmitDelegateCallArg on a windows bot. I made
changes to EmitDelegateCallArg so that it doesn't try to deactivate
cleanups for structs that have trivial destructors (cleanups for those
structs are never pushed to the cleanup stack in EmitParmDecl).

rdar://problem/39194693

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

llvm-svn: 331020
2018-04-27 06:57:00 +00:00
Rainer Orth f0f716df8e [Solaris] __float128 is supported on Solaris/x86
When rebasing https://reviews.llvm.org/D40898 with GCC 5.4 on Solaris 11.4, I ran
into a few instances of

In file included from /vol/llvm/src/compiler-rt/local/test/asan/TestCases/Posix/asan-symbolize-sanity-test.cc:19:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/string:40:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:59:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/move.h:57:
/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/type_traits:311:39: error: __float128 is not supported on this target

  struct __is_floating_point_helper<__float128>
                                    ^

during make check-all.  The line above is inside

#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)

  template<>
    struct __is_floating_point_helper<__float128>
    : public true_type { };

#endif

While the libstdc++ header indicates support for __float128, clang does not, but
should.  The following patch implements this and fixed those errors.

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

llvm-svn: 330572
2018-04-23 09:28:08 +00:00
Steven Wu 79cbd1163a [CXX] Templates specialization visibility can be wrong
Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.

This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953

Reviewers: rsmith, arphaman, doug.gregor

Reviewed By: doug.gregor

Subscribers: doug.gregor, cfe-commits

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

llvm-svn: 330338
2018-04-19 15:46:43 +00:00
Akira Hatanaka 4ce0e5a892 [CodeGen] Do not push a destructor cleanup for a struct that doesn't
have a non-trivial destructor.

This fixes a bug introduced in r328731 where CodeGen emits calls to
synthesized destructors for non-trivial C structs in C++ mode when the
struct passed to EmitCallArg doesn't have a non-trivial destructor.
Under Microsoft's ABI, ASTContext::isParamDestroyedInCallee currently
always returns true, so it's necessary to check whether the struct has a
non-trivial destructor before pushing a cleanup in EmitCallArg.

This fixes PR37146.

llvm-svn: 330304
2018-04-18 23:33:15 +00:00
Reid Kleckner 54a33d7a27 [MS] Fix unprototyped thunk emission for incomplete return types
Fixes PR37161

llvm-svn: 330303
2018-04-18 23:21:32 +00:00
Erich Keane 5da1e69156 Add Microsoft mangling for _Float16
Enables _Float16 on Windows by creating a mangling
mechanism in MicrosoftMangle.  It accomplishes this by 
mangling as a structure type of __clang::_Float16, similar
to how Complex works.

Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D45738

llvm-svn: 330225
2018-04-17 22:00:54 +00:00
Brock Wyma 94ece8fbc9 [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...
When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code.  This initial support only
handles standard thunk ordinals.

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

llvm-svn: 330132
2018-04-16 16:53:57 +00:00
Richard Smith 269c26ab9b Generalize test for 32-bit targets.
llvm-svn: 329467
2018-04-07 00:28:32 +00:00
Richard Smith eea7062c3a Don't assume constructors return void.
Should fix ARM buildbot.

llvm-svn: 329449
2018-04-06 20:06:02 +00:00
Alexander Kornienko 2a8c18d991 Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

  archtype
  cas
  classs
  checkk
  compres
  definit
  frome
  iff
  inteval
  ith
  lod
  methode
  nd
  optin
  ot
  pres
  statics
  te
  thru

Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)

Differential revision: https://reviews.llvm.org/D44188

llvm-svn: 329399
2018-04-06 15:14:32 +00:00
Richard Smith e78fac5126 PR36992: do not store beyond the dsize of a class object unless we know
the tail padding is not reused.

We track on the AggValueSlot (and through a couple of other
initialization actions) whether we're dealing with an object that might
share its tail padding with some other object, so that we can avoid
emitting stores into the tail padding if that's the case. We still
widen stores into tail padding when we can do so.

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

llvm-svn: 329342
2018-04-05 20:52:58 +00:00
Manoj Gupta 4b3eefa5e8 Disable -fmerge-all-constants as default.
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).

Fixes PR18538.

Reviewers: rjmccall, rsmith, chandlerc

Reviewed By: rsmith, chandlerc

Subscribers: srhines, cfe-commits

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

llvm-svn: 329300
2018-04-05 15:29:52 +00:00
Saleem Abdulrasool 13aeee0d36 CodeGenCXX: support PreserveMostCC in MS ABI
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime.  Add support for this.  This allows the swift runtime to
be built for Windows again.

llvm-svn: 329025
2018-04-02 22:25:50 +00:00
Reid Kleckner 399d96e39c [MS] Emit vftable thunks for functions with incomplete prototypes
Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:

  struct Incomplete;
  struct A {
    virtual A* foo(Incomplete p) = 0;
  };
  struct B : virtual A {
    void foo(Incomplete p) override;
  };
  struct C : B { int c; };

This TU is valid, but lacks a definition of 'Incomplete', which makes it
hard to build a thunk for the final overrider, B::foo.

Before this change, Clang gives up attempting to emit the thunk, because
it assumes that if the parameter types are incomplete, it must be
emitting the thunk for optimization purposes. This is untrue for the MS
ABI, where the implementation of B::foo has no idea what thunks C's
vftable may require. Clang needs to emit the thunk without necessarily
having access to the complete prototype of foo.

This change makes Clang emit a musttail variadic call when it needs such
a thunk. I call these "unprototyped" thunks, because they only prototype
the "this" parameter, which must always come first in the MS C++ ABI.

These thunks work, but they create ugly LLVM IR. If the call to the
thunk is devirtualized, it will be a call to a bitcast of a function
pointer. Today, LLVM cannot inline through such a call, but I want to
address that soon, because we also use this pattern for virtual member
pointer thunks.

This change also implements an old FIXME in the code about reusing the
thunk's computed CGFunctionInfo as much as possible. Now we don't end up
computing the thunk's mangled name and arranging it's prototype up to
around three times.

Fixes PR25641

Reviewers: rjmccall, rsmith, hans

Subscribers: Prazek, cfe-commits

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

llvm-svn: 329009
2018-04-02 20:20:33 +00:00
John McCall 4fcd9ef673 Fix a major swiftcall ABI bug with trivial C++ class types.
The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it.  Relying on Sema's
computation seems much more reliable.

Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).

This does mean that we have a less portable rule for deciding
indirectness for swiftcall.  I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.

This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime.  It doesn't affect normal Swift
operation because we don't import code as C++.

llvm-svn: 328942
2018-04-01 21:04:30 +00:00
Rafael Espindola c9643d8fc8 Set dso_local when clearing dllimport.
llvm-svn: 328801
2018-03-29 16:45:18 +00:00
Matt Arsenault fd00e6065a Fix typo
llvm-svn: 328791
2018-03-29 14:31:59 +00:00
Akira Hatanaka fcbe17c6be [ObjC++] Make parameter passing and function return compatible with ObjC
ObjC and ObjC++ pass non-trivial structs in a way that is incompatible
with each other. For example:
    
typedef struct {
  id f0;
  __weak id f1;
} S;
    
// this code is compiled in c++.
extern "C" {
  void foo(S s);
}
    
void caller() {
  // the caller passes the parameter indirectly and destructs it.
  foo(S());
}
    
// this function is compiled in c.
// 'a' is passed directly and is destructed in the callee.
void foo(S a) {
}
    
This patch fixes the incompatibility by passing and returning structs
with __strong or weak fields using the C ABI in C++ mode. __strong and
__weak fields in a struct do not cause the struct to be destructed in
the caller and __strong fields do not cause the struct to be passed
indirectly.
    
Also, this patch fixes the microsoft ABI bug mentioned here:
    
https://reviews.llvm.org/D41039?id=128767#inline-364710
    
rdar://problem/38887866
    
Differential Revision: https://reviews.llvm.org/D44908

llvm-svn: 328731
2018-03-28 21:13:14 +00:00
Reid Kleckner eed882022f [MS] Fix bug in method vfptr location code
We were assuming that vbtable indices were assigned in layout order in
our comparison, which is not the case. When a virtual method, such as
the destructor, appears in multiple vftables, the vftable that appears
first in object layout order is the one that points to the main
implementation of that method. The later vftables use thunks.

In this layout, we adjusted "this" in the main implementation by the
amount that is appropriate for 'B' instead of 'A', even though the main
implementation is found in D's vftable for A:

  struct A {
    virtual ~A() {}
  };
  struct B {
    virtual ~B() {}
  };
  struct C : virtual B {};
  struct D : virtual A, C {};

D's layout looks like:
   0 D subobject (empty)
   0 C base suboject
   8 A base subobject
  16 B base subobject

With this fix, we correctly adjust by -8 in D's deleting destructor
instead of -16.

Fixes PR36921.

llvm-svn: 328723
2018-03-28 18:23:35 +00:00
Carlos Alberto Enciso 01ae6f2c5f [SemaCXX] _Pragma("clang optimize off") not affecting lambda.
Declaring "_Pragma("clang optimize off")" before the body of a
function with a lambda leads to the lambda functions in the body
not being affected.

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

llvm-svn: 328494
2018-03-26 13:48:03 +00:00
Rafael Espindola fe9a55a3f1 Bring r328238 back with a fix.
The issues was that we were setting hidden visibility if, when
processing a hidden class, we found out that we needed to emit a
reference to a vtable provided by the standard library.

Original message:

Set dso_local on vtables.

llvm-svn: 328288
2018-03-23 01:36:23 +00:00
Rafael Espindola 1c40647e1c Set dso_local on __ImageBase.
llvm-svn: 328266
2018-03-22 23:02:19 +00:00
Rafael Espindola f377a57da9 Add a test.
This would have found the regression in r328238.

llvm-svn: 328263
2018-03-22 22:57:48 +00:00
Rafael Espindola f6688124b9 Revert "Set dso_local on vtables."
This reverts commit r328238.

Looks like it broke some buildbots.

llvm-svn: 328242
2018-03-22 21:14:16 +00:00
Rafael Espindola e006b8f486 Set dso_local on vtables.
llvm-svn: 328238
2018-03-22 20:33:01 +00:00
Eric Fiselier fa752f23cc [Builtins] Overload __builtin_operator_new/delete to allow forwarding to usual allocation/deallocation functions.
Summary:
Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins.

See llvm.org/PR22634 for more information about the libc++ bug.

This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued.

One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled.


In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`.

Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak

Reviewed By: rsmith

Subscribers: cfe-commits

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

llvm-svn: 328134
2018-03-21 19:19:48 +00:00
Rafael Espindola 6ab4ae4168 Set dso_local on runtime variables.
llvm-svn: 328068
2018-03-21 01:30:16 +00:00
Rafael Espindola 0d40f12596 Set dso_local on string literals.
llvm-svn: 328040
2018-03-20 20:42:55 +00:00
Rafael Espindola 3c9be62d24 Set dso_local for runtime function.
This is another case where there is special logic for adding dllimport
and so we cannot use setGVProperties.

llvm-svn: 328036
2018-03-20 20:27:30 +00:00
Rafael Espindola ca08d2402f Set dso_local for guid decls.
llvm-svn: 327991
2018-03-20 15:42:58 +00:00
George Burgess IV 18b28a86c1 Properly construct `inline` members without initializers
Digging through commit logs, it appears the checks in this block predate
`inline` class variables. With them, we fail to emit dynamic
initializers for members that don't have an explicit initializer, and we
won't go out of our way to instantiate the class denoted by
`Var->getType()`.

Fixes PR35599.

llvm-svn: 327945
2018-03-20 03:27:44 +00:00
Akira Hatanaka 797afe3a4e [CodeGen] Ignore OpaqueValueExprs that are unique references to their
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.

Previously the loop in emitPseudoObjectExpr would emit the IR for each
OpaqueValueExpr that was in a PseudoObjectExpr's semantic-form
expression list and use the result when the OpaqueValueExpr later
appeared in other expressions. This caused an assertion failure when
AggExprEmitter tried to copy the result of an OpaqueValueExpr and the
copied type didn't have trivial copy/move constructors or assignment
operators.

This patch adds flag IsUnique to OpaqueValueExpr which indicates it is a
unique reference to its source expression (it is not used in multiple
places). The loop in emitPseudoObjectExpr ignores OpaqueValueExprs that
are unique and CodeGen visitors simply traverse the source expressions
of such OpaqueValueExprs.

rdar://problem/34363596

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

llvm-svn: 327939
2018-03-20 01:47:58 +00:00
Reid Kleckner 281032584d [MS] Fix bug in r327732 with devirtualized complete destructor calls
llvm-svn: 327754
2018-03-16 22:20:57 +00:00
Reid Kleckner 332a3e075f [MS] Fix tests after r327738 that only fail with a default Windows target
llvm-svn: 327741
2018-03-16 20:53:13 +00:00
Reid Kleckner 1a0c39ae0b [MS] Commit some changes that were intended to be part of r327738
llvm-svn: 327739
2018-03-16 20:37:59 +00:00
Reid Kleckner fb93154bf1 [MS] Don't escape MS C++ names with \01
It is not needed after LLVM r327734. Now it will be easier to copy-paste
IR symbol names from Clang.

llvm-svn: 327738
2018-03-16 20:36:49 +00:00
Reid Kleckner ae9b070111 [MS] Always use base dtors in place of complete/vbase dtors when possible
Summary:
Previously we tried too hard to uphold the fiction that destructor
variants work like they do on Itanium throughout the ABI-neutral parts
of clang. This lead to MS C++ ABI incompatiblities and other bugs. Now,
-mconstructor-aliases will no longer control this ABI detail, and clang
-cc1's LLVM IR output will be this much closer to the clang driver's.

Based on a patch by Zahira Ammarguellat:
  https://reviews.llvm.org/D39063

I've tried to move the logic that Zahira added into MicrosoftCXXABI.cpp.
There is only one ABI-specific detail sticking out, and that is in
CodeGenModule::getAddrOfCXXStructor, where we collapse complete dtors to
base dtors in the MS ABI.

This fixes PR32990.

Reviewers: erichkeane, zahiraam, majnemer, rjmccall

Subscribers: cfe-commits

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

llvm-svn: 327732
2018-03-16 19:40:50 +00:00
Yaxun Liu 5b330e8d61 Recommit r326946 after reducing CallArgList memory footprint
llvm-svn: 327634
2018-03-15 15:25:19 +00:00
Yaxun Liu 0bc0859a00 Remove test deep-ast-tree.cpp
Since there is no reliable way to change the AST depth of this test by supported stack size
of the test environment, remove this test for now.

llvm-svn: 327578
2018-03-14 21:40:55 +00:00
Yaxun Liu 25fb15a08f Reduce AST depth for test deep-ast-tree.cpp for atom
llvm-svn: 327570
2018-03-14 20:41:05 +00:00
Yaxun Liu ac57bcc8b7 Attempt to fix failure of deep-ast-tree.cpp on atom and s390
llvm-svn: 327547
2018-03-14 18:24:38 +00:00
Rafael Espindola 3f727a8f3a Set dso_local on external rtti GVs.
In this particular case it would be possible to just add an else with
CGM.setDSOLocal(GV), but it seems better to have as many callers as
possible just call setGVProperties so that we can centralize the logic
there.

This patch then makes setGVProperties able to handle null Decls.

llvm-svn: 327543
2018-03-14 18:14:46 +00:00
Yaxun Liu e392ce4315 Attempt to fix failure of deep-ast-tree.cpp on ppc64 and atom
llvm-svn: 327529
2018-03-14 16:47:49 +00:00
Yaxun Liu 23137a1e45 Add deep AST tree test for r327515
llvm-svn: 327516
2018-03-14 15:03:31 +00:00