deadal nix via llvm-dev
2015-Sep-06 09:19 UTC
[llvm-dev] LLVMBuildLandingPad is wrong on 3.7
Hi all, During the dev in between 3.6 and the release of 3.7, the personality function was moved from the landingpad to the function itself. During theses events, LLVMBuildLandingPad was changed, twice. The first time in a backward incompatible way, the second in a backward compatible way. As things are now, the backward incompatible way is in 3.7 and the backward compatible in master. Meaning master is backward compatible with 3.6 but not 3.7. That is bad. If there is ever a plan for 3.7.1, that'd be great to cherry pick 7c898facbc5c707c77f25f7fd9b512a099af62a8 . Alternatively, master can be made compatible with 3.7 . I'd like to add that having some actual testing for the C API would have prevented the whole confusion in the first place. I have a diff out to start moving in that direction: http://reviews.llvm.org/D10725 . The damn thing is out since June and nothing have moved since then. If core devs are swaped and can't handle this, please delegate. I know there is some discussion about the state of the C API, but the thread is dead for weeks now, reasonable options have been presented, and I'm not sure what is expected to move things here. ALL alternative proposed in the thread pretty much are better than the status quo. I'm not sure what is expected for thing to move forward. It seems that cores devs just aren't using that API, but people actually using it or willing to work on it lack the power to do so. Please make something happen. Sooner rather than later. I'm here to help, but really, if 2.5 month is what is required to get a test in, I'd be probably dead of old age before being able to have any significant impact. Same goes for others C API users. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150906/c4f77a15/attachment.html>
Reid Kleckner via llvm-dev
2015-Sep-08 15:38 UTC
[llvm-dev] LLVMBuildLandingPad is wrong on 3.7
That really sucks. I wasn't aware that we fixed it after the branch point. We could merge it and try to rush out a 3.7.1 release, but I think Hans is all release-d out for now. Given that we already broke compatibility in a released version of LLVM, I'd be OK removing the compatibility hack and shipping the modified LLVMBuildLandingPad. Personalities no longer live on landingpads. On Sun, Sep 6, 2015 at 2:19 AM, deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > During the dev in between 3.6 and the release of 3.7, the personality > function was moved from the landingpad to the function itself. > > During theses events, LLVMBuildLandingPad was changed, twice. The first > time in a backward incompatible way, the second in a backward compatible > way. > > As things are now, the backward incompatible way is in 3.7 and the > backward compatible in master. > > Meaning master is backward compatible with 3.6 but not 3.7. > > That is bad. If there is ever a plan for 3.7.1, that'd be great to cherry > pick 7c898facbc5c707c77f25f7fd9b512a099af62a8 . Alternatively, master can > be made compatible with 3.7 . > > I'd like to add that having some actual testing for the C API would have > prevented the whole confusion in the first place. I have a diff out to > start moving in that direction: http://reviews.llvm.org/D10725 . The damn > thing is out since June and nothing have moved since then. > > If core devs are swaped and can't handle this, please delegate. I know > there is some discussion about the state of the C API, but the thread is > dead for weeks now, reasonable options have been presented, and I'm not > sure what is expected to move things here. ALL alternative proposed in the > thread pretty much are better than the status quo. I'm not sure what is > expected for thing to move forward. It seems that cores devs just aren't > using that API, but people actually using it or willing to work on it lack > the power to do so. > > Please make something happen. Sooner rather than later. I'm here to help, > but really, if 2.5 month is what is required to get a test in, I'd be > probably dead of old age before being able to have any significant impact. > Same goes for others C API users. > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/b64f4aed/attachment.html>
Hans Wennborg via llvm-dev
2015-Sep-10 22:20 UTC
[llvm-dev] LLVMBuildLandingPad is wrong on 3.7
+Tom Sorry, I should have noticed that the C API changed. Looks like the fix is now merged in r247191. However, that means the API is changing between 3.7.0 and 3.7.1 :-/ I don't know if that's better or worse though. On Tue, Sep 8, 2015 at 8:38 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> That really sucks. I wasn't aware that we fixed it after the branch point. > We could merge it and try to rush out a 3.7.1 release, but I think Hans is > all release-d out for now. > > Given that we already broke compatibility in a released version of LLVM, I'd > be OK removing the compatibility hack and shipping the modified > LLVMBuildLandingPad. Personalities no longer live on landingpads. > > On Sun, Sep 6, 2015 at 2:19 AM, deadal nix via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> During the dev in between 3.6 and the release of 3.7, the personality >> function was moved from the landingpad to the function itself. >> >> During theses events, LLVMBuildLandingPad was changed, twice. The first >> time in a backward incompatible way, the second in a backward compatible >> way. >> >> As things are now, the backward incompatible way is in 3.7 and the >> backward compatible in master. >> >> Meaning master is backward compatible with 3.6 but not 3.7. >> >> That is bad. If there is ever a plan for 3.7.1, that'd be great to cherry >> pick 7c898facbc5c707c77f25f7fd9b512a099af62a8 . Alternatively, master can be >> made compatible with 3.7 . >> >> I'd like to add that having some actual testing for the C API would have >> prevented the whole confusion in the first place. I have a diff out to start >> moving in that direction: http://reviews.llvm.org/D10725 . The damn thing is >> out since June and nothing have moved since then. >> >> If core devs are swaped and can't handle this, please delegate. I know >> there is some discussion about the state of the C API, but the thread is >> dead for weeks now, reasonable options have been presented, and I'm not sure >> what is expected to move things here. ALL alternative proposed in the thread >> pretty much are better than the status quo. I'm not sure what is expected >> for thing to move forward. It seems that cores devs just aren't using that >> API, but people actually using it or willing to work on it lack the power to >> do so. >> >> Please make something happen. Sooner rather than later. I'm here to help, >> but really, if 2.5 month is what is required to get a test in, I'd be >> probably dead of old age before being able to have any significant impact. >> Same goes for others C API users.
Apparently Analagous Threads
- Request to merge r242372 into the 3.7 branch: Fix for C API incompatibility between 3.6 and 3.7.
- Request to merge r242372 into the 3.7 branch: Fix for C API incompatibility between 3.6 and 3.7.
- [LLVMdev] [RFC] Developer Policy for LLVM C API
- [LLVMdev] [RFC] Developer Policy for LLVM C API
- [LLVMdev] Aggregate store/load optimization