Commit Graph

16 Commits

Author SHA1 Message Date
Fangrui Song dbc96b518b Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"
This reverts commit 789a46f2d7.

Accidentally committed.
2020-02-03 10:09:39 -08:00
Fangrui Song 789a46f2d7 [CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition
Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865
2020-02-03 09:52:48 -08: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
Rafael Espindola 922f2aa9b2 Bring r325915 back.
The tests that failed on a windows host have been fixed.

Original message:

Start setting dso_local for COFF.

With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325940
2018-02-23 19:30:48 +00:00
Rafael Espindola 43ce3a3a4d Revert "Start setting dso_local for COFF."
This reverts commit r325915.

It will take some time to fix the failures on a windows host.

llvm-svn: 325929
2018-02-23 18:09:29 +00:00
Rafael Espindola 004d240b6a Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325915
2018-02-23 15:32:32 +00:00
Richard Smith f667ad5f98 Add flag to request Clang is ABI-compatible with older versions of itself
This patch adds a flag -fclang-abi-compat that can be used to request that
Clang attempts to be ABI-compatible with some older version of itself.

This is provided on a best-effort basis; right now, this can be used to undo
the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return
by value of class types affected by that change, and to undo the ABI change in
r262688, reverting Clang to using integer registers rather than SSE registers
for passing <1 x long long> vectors. The intent is that we will maintain this
backwards compatibility path as we make ABI-breaking fixes in future.

The reversion to the old behavior for r310401 is also applied to the PS4 target
since that change is not part of its platform ABI (which is essentially to do
whatever Clang 3.2 did).

llvm-svn: 311823
2017-08-26 01:04:35 +00:00
Richard Smith 96cd671cd6 PR19668, PR23034: Fix handling of move constructors and deleted copy
constructors when deciding whether classes should be passed indirectly.

This fixes ABI differences between Clang and GCC:

 * Previously, Clang ignored the move constructor when making this
   determination. It now takes the move constructor into account, per
   https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
   seem recent, but the ABI change was agreed on the Itanium C++ ABI
   list a long time ago).

 * Previously, Clang's behavior when the copy constructor was deleted
   was unstable -- depending on whether the lazy declaration of the
   copy constructor had been triggered, you might get different behavior.
   We now eagerly declare the copy constructor whenever its deletedness
   is unclear, and ignore deleted copy/move constructors when looking for
   a trivial such constructor.

This also fixes an ABI difference between Clang and MSVC:

 * If the copy constructor would be implicitly deleted (but has not been
   lazily declared yet), for instance because the class has an rvalue
   reference member, we would pass it directly. We now pass such a class
   indirectly, matching MSVC.

Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
Schmidt, which was based on a patch by Reid Kleckner!

This is a re-commit of r310401, which was reverted in r310464 due to ARM
failures (which should now be fixed).

llvm-svn: 310983
2017-08-16 01:49:53 +00:00
Diana Picus 0c9f193acc Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly."
This reverts commit r310401 because it seems to have broken some ARM
bot(s).

llvm-svn: 310464
2017-08-09 12:22:25 +00:00
Richard Smith f1a425edb7 PR19668, PR23034: Fix handling of move constructors and deleted copy
constructors when deciding whether classes should be passed indirectly.

This fixes ABI differences between Clang and GCC:

 * Previously, Clang ignored the move constructor when making this
   determination. It now takes the move constructor into account, per
   https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
   seem recent, but the ABI change was agreed on the Itanium C++ ABI
   list a long time ago).

 * Previously, Clang's behavior when the copy constructor was deleted
   was unstable -- depending on whether the lazy declaration of the
   copy constructor had been triggered, you might get different behavior.
   We now eagerly declare the copy constructor whenever its deletedness
   is unclear, and ignore deleted copy/move constructors when looking for
   a trivial such constructor.

This also fixes an ABI difference between Clang and MSVC:

 * If the copy constructor would be implicitly deleted (but has not been
   lazily declared yet), for instance because the class has an rvalue
   reference member, we would pass it directly. We now pass such a class
   indirectly, matching MSVC.

llvm-svn: 310401
2017-08-08 19:12:28 +00:00
Peter Collingbourne bad8e511d9 Fix -Asserts build, and add some more test cases.
llvm-svn: 287602
2016-11-22 00:43:30 +00:00
Peter Collingbourne 120eb54422 Sema, CodeGen: Ensure that an implicit copy ctor is available more often under the Microsoft C++ ABI.
This is needed because whether the constructor is deleted can control whether
we pass structs by value directly.

To fix this properly we probably want a more direct way for CodeGen to ask
whether the constructor was deleted.

Fixes PR31049.

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

llvm-svn: 287600
2016-11-22 00:21:43 +00:00
Hans Wennborg 2151d12ec0 Fix CHECK directives that weren't checking.
llvm-svn: 246492
2015-08-31 21:48:52 +00:00
David Blaikie a953f2825b Update Clang tests to handle explicitly typed load changes in LLVM.
llvm-svn: 230795
2015-02-27 21:19:58 +00:00
Reid Kleckner d355ca77a9 Revert Itanium parts of "Don't copy objects with trivial, deleted copy ctors"
This undoes half of r208786.

It had problems with lazily declared special members in cases like this:
  struct A {
    A();
    A &operator=(A &&o);
    void *p;
  };
  void foo(A);
  void bar() {
    foo({});
  }

In this case, the copy and move constructors are implicitly deleted.
However, Clang doesn't eagerly declare the copy ctor in the AST, so we
pass the struct in registers.  Furthermore, GCC passes this in registers
even though this class should be uncopyable.

Revert this for now until the dust settles.

llvm-svn: 208836
2014-05-15 01:26:32 +00:00
Reid Kleckner cf87e10f9d Don't copy objects with trivial, deleted copy ctors
This affects both the Itanium and Microsoft C++ ABIs.

This is in anticipation of a change to the Itanium C++ ABI, and should
match GCC's current behavior.  The new text will likely be:

"""
Pass an object of class type by value if every copy constructor and
move constructor is deleted or trivial and at least one of them is not
deleted, and the destructor is trivial.
"""
http://sourcerytools.com/pipermail/cxx-abi-dev/2014-May/002728.html

On x86 Windows, we can mostly use the same logic, where we use inalloca
instead of passing by address.  However, on Win64, there are register
parameters, and we have to do what MSVC does.  MSVC ignores the presence
of non-trivial move constructors and only considers the presence of
non-trivial or deleted copy constructors.  If a non-trivial or deleted
copy ctor is present, it passes the argument indirectly.

This change fixes bugs and makes us more ABI compatible with both GCC
and MSVC.

Fixes PR19668.

Reviewers: rsmith

Differential Revision: http://reviews.llvm.org/D3660

llvm-svn: 208786
2014-05-14 16:02:09 +00:00