[llvm-dev] LLVMBuildLandingPad is wrong on 3.7

[deadal nix via llvm-dev]

Better only have 3.7 broken and 3.7.1 and onward working rather than break
things multiple time. Vanilla 3.7 would need to be avoided by C API users.
That is the most manageable option. Because C do not mangle signature,
linking against the wrong version of LLVM won't cause any error, simply a
program that segfault when calling the function.

2015-09-10 15:20 GMT-07:00 Hans Wennborg <hans at chromium.org>:

> +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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150910/f503cfa1/attachment-0001.html>