jroelofs accepted this revision.
jroelofs added a comment.
This revision is now accepted and ready to land.
LGTM
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/c
zatrazz added a comment.
Ping (x2).
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zatrazz added a comment.
Ping.
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zatrazz updated this revision to Diff 67850.
zatrazz added a comment.
I think patch should be safe now.
https://reviews.llvm.org/D23420
Files:
test/libcxx/test/target_info.py
Index: test/libcxx/test/target_info.py
===
--- test/l
zatrazz added a comment.
In https://reviews.llvm.org/D23420#513824, @jroelofs wrote:
> In https://reviews.llvm.org/D23420#513820, @zatrazz wrote:
>
> > Yes, although in pratice for shared libraries this is not an issue (at
> > least on Linux with current linker strategies). And I open for sugges
jroelofs added a comment.
In https://reviews.llvm.org/D23420#513820, @zatrazz wrote:
> Yes, although in pratice for shared libraries this is not an issue (at least
> on Linux with current linker strategies). And I open for suggestion on how to
> proceed in this case since we have some other opt
zatrazz added a comment.
Yes, although in pratice for shared libraries this is not an issue (at least on
Linux with current linker strategies). And I open for suggestion on how to
proceed in this case since we have some other options:
1. Add the required soft-sp implementations when building fo
jroelofs added a comment.
This breaks the ODR... the behavior under those circumstances is undefined.
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zatrazz added a comment.
Yes, but my understaning is the proposed link order will force libc++ to link
against _Unwind* symbols from libunwind (this is what I am observing also).
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-comm
jroelofs added a comment.
Doesn't libgcc_s contain bits of gcc's unwinder?
https://reviews.llvm.org/D23420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zatrazz updated this revision to Diff 67835.
zatrazz added a comment.
What about this version? The only difference is for libunwind libgcc is still
included.
https://reviews.llvm.org/D23420
Files:
test/libcxx/test/target_info.py
Index: test/libcxx/test/target_info.py
===
zatrazz added a comment.
I tried to find why exactly libgcc has to appear before and after but I
couldn't get any information from commit history. On my system (aarch64/linux)
I am also getting "-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s"
"-lgcc".
I think we can got by the safe
EricWF added a subscriber: EricWF.
EricWF added a reviewer: EricWF.
EricWF added a comment.
Urg... Not this again. This link order is important. I can't remember *why*,
but libgcc has to appear both before and after `pthread` and `libc` IIRC.
Either way the intention here is to mimic the output
rmaprath added a subscriber: rmaprath.
rmaprath added a comment.
I too noticed this very recently (on our non-bare-metal builds), and wondered
why these dependencies are not included by default. Thanks for looking into it.
I'll let someone familiar with the details approve.
https://reviews.llv
zatrazz created this revision.
zatrazz added reviewers: jroelofs, danalbert.
zatrazz added subscribers: rengolin, cfe-commits.
Herald added a subscriber: aemerson.
Some tests uses 'long double' to/from conversions and for some targets
they are provided by compiler runtime (either compiler-rt or li
15 matches
Mail list logo
