!!! 3.2 Release RC2 deadline November 29th

Hello,

Just a quick reminder that the November 29th (10p.m. PST) is the
end of Phase 1 testing and Release Candidate 2 (RC2) deadline.
After RC2 deadline, LLVM-Clang 3.2 release will be considered feature
complete and no new functionality can be added.

With 2 days left please use following guidelines when
initiating request for patches before RC2 deadline.

I will be happy to merge *approved* patches for low risk/
crash fixes that merge cleanly and have simple test case or
procedure to verify correctness (aka 1040 EZ Patch).

Patches that do not fall under the above category need to
be classified as either release blocking (discussed below)
or non release blocking and thus not included in this release.

Code owners

I need your input on the state of the release blocking issues as
listed in the Bug 13893 - "Umbrella bug for 3.2 release"

http://llvm.org/bugs/show_bug.cgi?id=13893.

Please review the list below and let me know whether the
listed bugs can be (better yet will be!) fixed in the Phase 2.

If there are other release stopping bugs/issues that you
think should be fixed before the final 3.2 release but
are not listed below then please add them to the
Bug 13893 - "Umbrella bug for 3.2 release".

As of today Tuesday Nov 27th following release blocking
bugs are still open:

12664 - O2 -ftree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns on
mdbx.f90 confuses dragoneg

13561 - LLVM ERROR: Cannot select: 0x14214bb10: i16 =
extract_vector_elt 0x14214b910, 0x142142c10

14116 - Inliner incorrectly combines cleanup and catch landing pads

14279 - mishandling of implicit move in class with copy-only member

14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning
v4f64 on ARM

14429 - Dragonegg fails to build clang

Pawel

Hello,

Just a quick reminder that the November 29th (10p.m. PST) is the
end of Phase 1 testing and Release Candidate 2 (RC2) deadline.
After RC2 deadline, LLVM-Clang 3.2 release will be considered feature
complete and no new functionality can be added.

With 2 days left please use following guidelines when
initiating request for patches before RC2 deadline.

I will be happy to merge *approved* patches for low risk/
crash fixes that merge cleanly and have simple test case or
procedure to verify correctness (aka 1040 EZ Patch).

Patches that do not fall under the above category need to
be classified as either release blocking (discussed below)
or non release blocking and thus not included in this release.

Code owners

I need your input on the state of the release blocking issues as
listed in the Bug 13893 - "Umbrella bug for 3.2 release"

http://llvm.org/bugs/show_bug.cgi?id=13893.

Please review the list below and let me know whether the
listed bugs can be (better yet will be!) fixed in the Phase 2.

If there are other release stopping bugs/issues that you
think should be fixed before the final 3.2 release but
are not listed below then please add them to the
Bug 13893 - "Umbrella bug for 3.2 release".

Just my two cents :wink:

As of today Tuesday Nov 27th following release blocking
bugs are still open:

12664 - O2 -ftree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns on
mdbx.f90 confuses dragoneg

13561 - LLVM ERROR: Cannot select: 0x14214bb10: i16 =
extract_vector_elt 0x14214b910, 0x142142c10

No action on this bug in 4 months. I don't think It shouldn't be a release blocker either.

14116 - Inliner incorrectly combines cleanup and catch landing pads

I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month.

14279 - mishandling of implicit move in class with copy-only member

This would be nice to have, but is self-host in C++11 mode currently tested by the build bots?

14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning
v4f64 on ARM

A great bug to fix, but ARM is not a supported target for release criteria unless someone wants to make this happen for 3.3. So unless it gets fixed soon, it shouldn't block the release.

14429 - Dragonegg fails to build clang

Dragonegg is a part of the release, but my question is.. is bootstrap only tested at release time (seems like some buildbots must test this)? This should be changed for 3.3. This seems like a more likely candidate to get fixed for 3.2 though.

Thanks for all your hard work with the release!

-Tanya

This bug means that we can't compile at anything over -O1, or we get code that does the wrong thing (e.g. terminate instead of catching an exception) if a function with a cleanup is inlined into one with a catch (or possibly the other way around). I would really like to see it fixed for 3.2, because it results in some fairly serious miscompilations. I discussed it with a few people at the DevMeeting.

David

We have 10 dragonegg builders in the buildbot.
8 of them bootstrap (all are green) but they build dragonegg with
dragonegg. 2 run test-suit.

Building clang with the dragonegg surely is a good test, but is this a
release requirement?
If it is, we need another builder.

-Galina

14116 - Inliner incorrectly combines cleanup and catch landing pads

I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month.

This bug means that we can't compile at anything over -O1, or we get code that does the wrong thing (e.g. terminate instead of catching an exception) if a function with a cleanup is inlined into one with a catch (or possibly the other way around). I would really like to see it fixed for 3.2, because it results in some fairly serious miscompilations. I discussed it with a few people at the DevMeeting.

So why isn't this caught by any of the regression testing (testsuite) if it nothing above -O1 can be compiled? I assume you mean for your project?

I'm trying to understand how large of a problem this is. Ideally, we want everything we can to get fixed.. but since there is some confusion and debate on this bug, I'm thinking its not a quick or easy fix.

-Tanya

We have 10 dragonegg builders in the buildbot.
8 of them bootstrap (all are green) but they build dragonegg with
dragonegg. 2 run test-suit.

Building clang with the dragonegg surely is a good test, but is this a
release requirement?
If it is, we need another builder.

I agree that if it is a release requirement it should have a builder. Since one does not exist now, I would rather it not be a release blocker (but it would be great if someone could fix it).

-Tanya

So why isn't this caught by any of the regression testing (testsuite) if it nothing above -O1 can be compiled? I assume you mean for your project?

Any Objective-C on non-Apple platforms that uses cleanups (including those Clang inserts for blocks) breaks in certain cases with inlining. There are also some cases in C++, and cases in LTO (or using C headers in C++) when C++ code and C code using __attribute__((cleanup)) are mixed. We have an ugly hack in clang that avoids it in the most common case, but there are almost certainly cases that we are not catching.

I'm trying to understand how large of a problem this is. Ideally, we want everything we can to get fixed.. but since there is some confusion and debate on this bug, I'm thinking its not a quick or easy fix.

There is no debate in the bug. The consensus (both in the bug report and in-person discussions at the DevMeeting) is that the inliner is doing an obviously wrong thing when it takes a function containing a catchall and one containing a cleanup, inlines one into the other, and ends up with one with just a cleanup. The discussion in the bug report is due to the fact that there are probably also some corner cases where the wrong thing happens, but the inliner bug is the serious one.

David

I absolutely agree that the inliner seems to be doing the wrong thing on your testcases, but IIRC, your testcases were all hand-written IR, and the inliner seemed to be doing the right thing for your original source-code testcase. I don't know of a reason why that should matter, but I'm hesitant to call this a release blocker if you can't duplicate this starting from source code, because it's possible that the inliner is only broken on "unrealistic" IR — which would still definitely be a bug, but not one that should hold up the release.

Just to be clear, anything that a major frontend like clang would emit for actual source code is ipso facto "realistic". I'm just asking that you find a way to duplicate with ObjC source, not with hand-written IR.

John.

Hi Tanya,

As of today Tuesday Nov 27th following release blocking
bugs are still open:

12664 - O2 -ftree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns on
mdbx.f90 confuses dragoneg

13561 - LLVM ERROR: Cannot select: 0x14214bb10: i16 =
extract_vector_elt 0x14214b910, 0x142142c10

No action on this bug in 4 months. I don't think It shouldn't be a release blocker either.

I have a fix!

14116 - Inliner incorrectly combines cleanup and catch landing pads

I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month.

14279 - mishandling of implicit move in class with copy-only member

This would be nice to have, but is self-host in C++11 mode currently tested by the build bots?

14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning
v4f64 on ARM

A great bug to fix, but ARM is not a supported target for release criteria unless someone wants to make this happen for 3.3. So unless it gets fixed soon, it shouldn't block the release.

14429 - Dragonegg fails to build clang

Dragonegg is a part of the release, but my question is.. is bootstrap only tested at release time (seems like some buildbots must test this)? This should be changed for 3.3. This seems like a more likely candidate to get fixed for 3.2 though.

Dragonegg+LLVM+GCC is bootstrapped on every commit. However the bootstrap
doesn't include clang, which is a mistake.

Ciao, Duncan.

Pawel,

Is it still not too late to merge these patches?

r168471
r168460
r168458
r168456
r168455
r168453
r168450
r168448

These patches fix a bug in mips backend’s GOT implementation and add support for big-GOT relocations.

Thank you.

Akira,

Pawel,

Is it still not too late to merge these patches?

r168471
r168460
r168458
r168456
r168455
r168453
r168450
r168448

These patches fix a bug in mips backend's GOT implementation and add
support for big-GOT relocations.

That's quite a list of patches! To get them into the
3.2 release you would first need to get approval from all
the code owners and then we would have to merge and test.
Frankly, I do not see how we could get all that done
without delaying the release, RC2 deadline is today
at 10p.m. PST.

Pawel

Okay, it’s probably too late. I shouldn’t try to get them in.