Yes, r318830 has made our libcxx buildbots green. The public ones should
become green as well.
Thanks,
Evgeny
-Original Message-
From: Billy O'Neal
Date: Wednesday, 22 November 2017 at 12:30
To: Evgeny Astigeevich
Cc: "reviews+d40065+public+cdf4c853d41b4...@reviews.llvm.org"
, Billy
Hi Billy,
These changes caused buildbot failures: tuple.by.type.fail.cpp Line 19: unknown
type name 'TEST_IGNORE_NODISCARD'
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14/builds/1109
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17/builds
eastig added a comment.
The issue is reported as:
https://llvm.org/bugs/show_bug.cgi?id=28954
https://reviews.llvm.org/D12689
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
eastig added a comment.
In http://reviews.llvm.org/D12689#249899, @rnk wrote:
> I think you need to address the feedback about avoiding dynamic
> initialization on stock non-Mac systems.
>
> Sent from phone
In my comment above I proposed a special macro to distinguish between dynamic
and stat
eastig added a comment.
Ping.
http://reviews.llvm.org/D12689
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
eastig updated this revision to Diff 34973.
eastig added a comment.
Added tests
http://reviews.llvm.org/D12689
Files:
include/ios
src/iostream.cpp
test/std/input.output/iostream.objects/narrow.stream.objects/cerr_init.pass.cpp
test/std/input.output/iostream.objects/narrow.stream.object
eastig added a comment.
In http://reviews.llvm.org/D12689#243674, @jroelofs wrote:
> A testcase would be good, regardless of which of the proposed fixes ends up
> being chosen.
I will write it.
http://reviews.llvm.org/D12689
___
cfe-commits mail
eastig added a comment.
In http://reviews.llvm.org/D12689#243592, @rsmith wrote:
> Can we instead fix this in Clang by ensuring that libc++ is put at the right
> position in the static link order so that its initializers run first?
> libc++'s avoidance of running iostreams init code from every
eastig added a comment.
In http://reviews.llvm.org/D12689#243295, @rnk wrote:
> I think a better approach would be to use
> `__attribute__((init_priority(101)))` on Linux and `#pragma init_seg(lib)` on
> Windows to ensure that libc++'s iostream initializer runs earlier.
Thank you for advice.
Ping.
Could anyone review the patch?
Kind regards,
Evgeny Astigeevich
-Original Message-
From: Evgeny Astigeevich [mailto:evgeny.astigeev...@arm.com]
Sent: 08 September 2015 11:00
To: Evgeny Astigeevich
Cc: cfe-commits@lists.llvm.org
Subject: [PATCH] D12689: [libc++][static linking] std s
eastig created this revision.
eastig added a subscriber: cfe-commits.
When an executable (e.g. for bare metal environment) is statically linked with
libc++ the following code might not work as expected:
```
#include
class Foo {
public:
Foo(int n) {
std::cout << "Hello World - " << n <<
11 matches
Mail list logo
