assigned to @zmodem

Hans could we consider #40038 to be a blocker for 9.0?

Hans could we consider #40038 to be a
blocker for 9.0?

Yes, added it.

I added llvm/llvm-bugzilla-archive#42827 as a blocker, please triage as appropriate. Thank you!

Hans could we consider #40038 to be a
blocker for 9.0?

Yes, added it.

Fixed in r367387. Do I need to create a new bug as a merge request?

Fixed in r367387. Do I need to create a new bug as a merge request?

(Forgot to reply here: no, I've merged it already as commented on the bug.)

I'd like to nominate #42266 as blocker. I'm hoping it's easy and low risk for someone who knows the right part of the build system.

Please merge r368104 (clang) and r367750 (LLVM) part. This fixes a regression since the 8.0 release. One part for addressing the issues for -O0 is still under review, but improving the situation for optimized builds is already a huge step.

Please merge r368104 (clang) and r367750 (LLVM) part. This fixes a
regression since the 8.0 release. One part for addressing the issues for -O0
is still under review, but improving the situation for optimized builds is
already a huge step.

I started with the LLVM patch, but it doesn't apply cleanly on the branch, for example, RISCVTargetLowering::getConstraintType() didn't exist when we branched.

Jörg or Bill, could you prepare a patch that applies cleanly against the branch?

Please merge r368104 (clang) and r367750 (LLVM) part. This fixes a
regression since the 8.0 release. One part for addressing the issues for -O0
is still under review, but improving the situation for optimized builds is
already a huge step.

I started with the LLVM patch, but it doesn't apply cleanly on the branch,
for example, RISCVTargetLowering::getConstraintType() didn't exist when we
branched.

Jörg or Bill, could you prepare a patch that applies cleanly against the
branch?

Actually, I just ended up merging r367403 to unblock it.

I've merged r367750 in r368421 and r368104(+368202) in r368422.

Should #42366 be a blocker? A reviewer of the fix suggested it should be.

is_base_of_union.pass.cpp fails in C++03. Maybe it should be a release blocker?

Nevermind, that is just on apple-clang-11.0.

Should #42366 be a blocker? A reviewer
of the fix suggested it should be.

Yes, that seems reasonable. I see it's marked as a blocker now.

Can llvm/llvm-bugzilla-archive#42924 be considered a blocker? It is causing timeouts for us when building with AddressSanitizer.

Can llvm/llvm-bugzilla-archive#42924 be considered a blocker? It
is causing timeouts for us when building with AddressSanitizer.

Sorry, I think it's too late to do anything about it for 9.0.0. I've put in on my list of things for 9.0.1.

Please #42188 Clang-cl -std=c++17 doesn't handle the constexpr symbol correctly. I looked at the recent clang commit. No one seems to be dealing with this issue. If this release is not blocked, clang 9.0 may fail on Windows.

Please #42188 Clang-cl -std=c++17
doesn't handle the constexpr symbol correctly. I looked at the recent clang
commit. No one seems to be dealing with this issue. If this release is not
blocked, clang 9.0 may fail on Windows.

Sorry, here is a correction, clang-cl -std=c++14 (9.0) did not handle constexpr, not -std=c++17.

Please #42188 Clang-cl -std=c++17
doesn't handle the constexpr symbol correctly. I looked at the recent clang
commit. No one seems to be dealing with this issue. If this release is not
blocked, clang 9.0 may fail on Windows.

Sorry, here is a correction, clang-cl -std=c++14 (9.0) did not handle
constexpr, not -std=c++17.

I had not seen this before. I'll take a look and reply on the bug.

I'd like to request that 43229 get triaged, and considered for 9.0.1 if not 9.0.0 . Thanks.

I'd like to request that 43229 get triaged, and considered for 9.0.1 if not
9.0.0 . Thanks.

I've put it on my 9.0.1 list.

The -final tag is in.

9.0.1 blockers are tracked by llvm/llvm-bugzilla-archive#43360

mentioned in issue #41820

mentioned in issue #41858

mentioned in issue #41920

mentioned in issue #41931

mentioned in issue #41948

mentioned in issue #41991

mentioned in issue #42010

mentioned in issue #42014