Please merge the fix for bug 31606, e.g. r291955 ("Generalize our tentative DR resolution for inheriting copy/move constructors to better match the pre-P0136R1 behavior")

(In reply to comment #1)
> Please merge the fix for bug 31606, e.g. r291955 ("Generalize our tentative
> DR resolution for inheriting copy/move constructors to better match the
> pre-P0136R1 behavior")

It's on my list, Richard just wanted it to bake on trunk for a bit before we merge. Thanks.

May I merge r292119 please? We hit this recently with -Wsystem-header builds, it's a left-over bug from the five-digit-revision age.

r292244 is a fix for a recent regression reported on NetBSD, i.e. -march=native -mno-sse41 would assert for no good reason. May I merge it?

(In reply to comment #3)
> May I merge r292119 please? We hit this recently with -Wsystem-header
> builds, it's a left-over bug from the five-digit-revision age.

(In reply to comment #4)
> r292244 is a fix for a recent regression reported on NetBSD, i.e.
> -march=native -mno-sse41 would assert for no good reason. May I merge it?

OK to both.

I've added bug 31685 so that we can merge the fix for bug 30543

Please merge the fix for bug 27685 - already fixed on master, but not on the branch

I'm not sure if we want to consider bug 31756 a release blocker, as it requires xray to identify setups that inhibit the use of rdtscp. I've asked Dean to comment here about it.

Bug 31547 is relatively serious for those of us who have to work with libgcc for compatibility reasons. It breaks e.g. building GNU sed 4.3 with clang on a Linux system using libgcc.

IMO this should be fixed for the release.

I'd like to request merging two revisions:

- [libunwind] r292723 from bug #30879 -- this fixes exception handling on x86 Linux for me;

- [lld] r293078 from bug #31745 -- this fixes stand-alone build with shared libraries.

I think XRay bug 31756 should *not* be considered a release blocker. There's quite a bit of work to do to probe and work-around the lack of rdtscp, and I wouldn't want to be blocking the release contingent on that being addressed.

(In reply to comment #10)
> I'd like to request merging two revisions:
> 
> - [libunwind] r292723 from bug #30879 -- this fixes exception handling on
> x86 Linux for me;

Merged as r293298

> - [lld] r293078 from bug #31745 -- this fixes stand-alone build with shared
> libraries.

r293289

Will llgo be released with 4.0 (It does have a release_40 branch and a 4.0.0rc1 tag, but isn't listed anywhere...)?

If so, should add bug 31786 to the blockers -- the fixes attached there are needed to make llgo compile on Linux.

(In reply to comment #13)
> Will llgo be released with 4.0 (It does have a release_40 branch and a
> 4.0.0rc1 tag, but isn't listed anywhere...)?
> 
> If so, should add bug 31786 to the blockers -- the fixes attached there are
> needed to make llgo compile on Linux.

I didn't tag or branch it, and I don't see any branch here: http://llvm.org/svn/llvm-project/llgo/branches/

I don't think llgo is part of the release process.

I would like to nominate rL293230 for inclusion into LLVM 4.0 it is a small fix that allows LLVM to build with the Intel 2017 toolchain.

I'd like to request that r292624 - "[mips] Fix debug information for __thread variable"
and r292117 - "[mips] Correct c.cond.fmt instruction definition" be merged for 4.0.

(In reply to comment #15)
> I would like to nominate rL293230 for inclusion into LLVM 4.0 it is a small
> fix that allows LLVM to build with the Intel 2017 toolchain.

I've replied on the commit email.

(In reply to comment #16)
> I'd like to request that r292624 - "[mips] Fix debug information for
> __thread variable"

r293664

> and r292117 - "[mips] Correct c.cond.fmt instruction definition" be merged
> for 4.0.

r293665.

One of our users discovered a problem with SafeStack. I suspect it may be too late to get it fixed for 4.0, but added it to this tracking bug to ensure it won't get lost.

(In reply to Ed Schouten from comment #18)
> One of our users discovered a problem with SafeStack. I suspect it may be
> too late to get it fixed for 4.0, but added it to this tracking bug to
> ensure it won't get lost.

It sounds like the revision that regressed that was in 3.9 too, so it's not a regression and too late for 4.0. I'll change it to be a 4.0.1 blocker instead.

The release has shipped, so closing this.

For 4.0.1 blockers, use PR32061.