<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 9, 2015, at 2:07 PM, Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">We knew this was an ABI break. Here was the logic for why we want it in the 3.7.1 release:<div class=""><br class=""></div><div class="">The C API is supposed to be stable. The fact that the 3.7.0 release contained a modified LLVMBuildLandingPad function was a bug. Anyone who relies on this API basically cannot use the 3.7.0 release. The set of users using the C API and dealing with EH is probably small, so we chose not a to rush out a 3.7.1 release with a fix for this. Instead, we let the fix roll into 3.7.1, which will now have a backwards compatible C API and ABI with pre 3.7.0 LLVM.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">Anyway, I don't really care whether this gets merged or not. I am not a stakeholder in the stability of the C API. I would really prefer it if the C API users voiced an opinion on whether they want the C API to be more stable or closer to LLVM's in memory representation.</div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>During the BoF at the LLVM Dev meeting, if I understood correctly (I hope other can confirm, Eric?), some people asked about this issue and it was said that 3.7.1 will take the fix.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Nov 9, 2015 at 9:29 AM, Tom Stellard <span dir="ltr" class=""><<a href="mailto:tom@stellard.net" target="_blank" class="">tom@stellard.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 28, 2015 at 05:32:17AM +0000, Eric Christopher wrote:<br class="">
> On Tue, Oct 27, 2015 at 8:15 PM Chris Lattner <<a href="mailto:sabre@nondot.org" class="">sabre@nondot.org</a>> wrote:<br class="">
><br class="">
> ><br class="">
> > > On Oct 27, 2015, at 8:10 AM, Tom Stellard <<a href="mailto:tom@stellard.net" class="">tom@stellard.net</a>> wrote:<br class="">
> > ><br class="">
> > > Hi Chris,<br class="">
> > ><br class="">
> > > I would like to get your opinion on merging r242372<br class="">
> > > (<a href="http://reviews.llvm.org/rL242372" rel="noreferrer" target="_blank" class="">http://reviews.llvm.org/rL242372</a>) into the 3.7 branch.<br class="">
> > > The signature of the C API function LLVMBuildLandingPad<br class="">
> > > changed from the 3.6.0 to 3.7.0 release, so the C API<br class="">
> > > is currently incompatible between these to releases.<br class="">
> ><br class="">
> > This is a narrow enough API that it is probably only used by a few<br class="">
> > clients. I’d be happy for us to do whatever those clients would like to<br class="">
> > see with this.<br class="">
> ><br class="">
><br class="">
> Normally I'd prefer not to change API in a point release, but I think it's<br class="">
> fine to change it back here to match the previous releases and current<br class="">
> trunk. Just needs something in the release notes.<br class="">
><br class="">
<br class="">
Adding the correct llvm-dev list this time...<br class="">
<br class="">
I've just realized that this patch changes the ABI and would make 3.7.0 and 3.7.1<br class="">
binary incompatible. I think breaking the stable ABI is worse than breaking the C API,<br class="">
so I would prefer to either drop this patch or come up with a work-around.<br class="">
<br class="">
One possible work-around would be to keep the LLVMBuildLandingPad signature the<br class="">
same and then add this to Core.h:<br class="">
<br class="">
#ifdef DEBUG // Not sure whether we should use this or ifndef NDEBUG<br class="">
#define LLVMBuildLandingPad(B, Ty, PersFn, Name) \<br class="">
dbgs() << "Warning: PersnFn parameter ignored. You must explicitly set the " \<br class="">
"personality function on the parent function with " \<br class="">
" LLVMSetPersonalityFn(). This behavior changed in LLVM 3.7"; \<br class="">
LLVMBuildLandingPad(B, Ty, Name)<br class="">
#else<br class="">
#define LLVMBuildLandingPad(B, Ty, PersFn, Name)<br class="">
LLVMBuildLandingPad(B, Ty, Name);<br class="">
<br class="">
I'm open to other suggestions. What do people think about this?<br class="">
<br class="">
-Tom<br class="">
<br class="">
<br class="">
><br class="">
><br class="">
> ><br class="">
> > -Chris<br class="">
> ><br class="">
> > ><br class="">
> > > Merging this commit will make the 3.7.1 C API compatible<br class="">
> > > with 3.6.x and current trunk, but it will make the 3.7.1 C API<br class="">
> > > incompatible with 3.7.0.<br class="">
> > ><br class="">
> > > Not merging this commit will mean the 3.7.x C API will<br class="">
> > > be incompatible with 3.6.x and current trunk, but<br class="">
> > > the C API for 3.7.0 and 3.7.1 will be compatible.<br class="">
> > ><br class="">
> > > It took me a while to wrap my head around this, let me know if you have<br class="">
> > > any questions.<br class="">
> > ><br class="">
> > > -Tom<br class="">
> ><br class="">
> ><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>