LLVM 3.4 Branch Freeze

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LLVM 3.4 Branch Freeze

Bill Wendling
The LLVM 3.4 branches are now frozen. We’re only accepting major, super horrible bug fixes from now on. The testers are going to do a third phase of testing, but it’s mostly to verify that we don’t have any major problems left.

Share and enjoy!
-bw


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
Bill, et al.,

There are still a number of open bug reports demonstrating miscompiles on x86 with small/reduced test cases. I propose that we either delay this release until these have been fixed, or plan on a point release in the near future. I recommend that we put out another two release candidates, one at the end of this week, and one after another two weeks or so, to allow for these outstanding issues to be resolved.

Specifically, I think that these issues should be resolved prior to the release of 3.4:

 PR18068 [BasicAA]
 PR18067 [GVN]
 PR16431 (multiple; I suspect covered by the previous two)
 PR17638 [IndVarSimplify]
 PR18223 [IndVarSimplify]
 PR17473 [LSR]
 PR18165 [LSR]
 PR16729 [Loop Vectorizer]
 PR17288 [Loop Vectorizer]
 PR18102 [x86 backend or CodeGen]
 PR18000 [x86 backend or CodeGen]
 PR17504 [x86 backend or CodeGen]
 PR17794
 PR17073
 PR16108

 PR18042 [LCSSA] (This hits an assert, but may miscompile with NDEBUG)

Of course, the same underlying bug may be causing more than one of these, and at least some of these are already being worked on. Thoughts?

Thanks again,
Hal

----- Original Message -----

> From: "Bill Wendling" <[hidden email]>
> To: "[hidden email] Developers" <[hidden email]>, "<[hidden email]> Mailing List"
> <[hidden email]>
> Sent: Thursday, December 12, 2013 1:14:46 AM
> Subject: [cfe-dev] LLVM 3.4 Branch Freeze
>
> The LLVM 3.4 branches are now frozen. We’re only accepting major,
> super horrible bug fixes from now on. The testers are going to do a
> third phase of testing, but it’s mostly to verify that we don’t have
> any major problems left.
>
> Share and enjoy!
> -bw
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Bill Wendling
That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.

-bw

On Dec 12, 2013, at 9:24 PM, Hal Finkel <[hidden email]> wrote:

> Bill, et al.,
>
> There are still a number of open bug reports demonstrating miscompiles on x86 with small/reduced test cases. I propose that we either delay this release until these have been fixed, or plan on a point release in the near future. I recommend that we put out another two release candidates, one at the end of this week, and one after another two weeks or so, to allow for these outstanding issues to be resolved.
>
> Specifically, I think that these issues should be resolved prior to the release of 3.4:
>
> PR18068 [BasicAA]
> PR18067 [GVN]
> PR16431 (multiple; I suspect covered by the previous two)
> PR17638 [IndVarSimplify]
> PR18223 [IndVarSimplify]
> PR17473 [LSR]
> PR18165 [LSR]
> PR16729 [Loop Vectorizer]
> PR17288 [Loop Vectorizer]
> PR18102 [x86 backend or CodeGen]
> PR18000 [x86 backend or CodeGen]
> PR17504 [x86 backend or CodeGen]
> PR17794
> PR17073
> PR16108
>
> PR18042 [LCSSA] (This hits an assert, but may miscompile with NDEBUG)
>
> Of course, the same underlying bug may be causing more than one of these, and at least some of these are already being worked on. Thoughts?
>
> Thanks again,
> Hal
>
> ----- Original Message -----
>> From: "Bill Wendling" <[hidden email]>
>> To: "[hidden email] Developers" <[hidden email]>, "<[hidden email]> Mailing List"
>> <[hidden email]>
>> Sent: Thursday, December 12, 2013 1:14:46 AM
>> Subject: [cfe-dev] LLVM 3.4 Branch Freeze
>>
>> The LLVM 3.4 branches are now frozen. We’re only accepting major,
>> super horrible bug fixes from now on. The testers are going to do a
>> third phase of testing, but it’s mostly to verify that we don’t have
>> any major problems left.
>>
>> Share and enjoy!
>> -bw
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

C Bergström
On 12/13/13 01:58 PM, Bill Wendling wrote:
> That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.
How is the release schedule and blockers decided - is there a policy? As
an open source project it seems sorta weird (to me) that rushing a
release is more important than "getting it right" - granted if it's
unlikely any fix date I can totally see your point..
---------
(bw - You do an awesome job of being release manager and please don't
take this as a critique - just curious)
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Anton Korobeynikov-2
The usual procedure is to make time-based releases. So - "release
trunk and make sure it's stable enough" plus - fix any outstanding
regressions.

There is some text wrt this:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström"
<[hidden email]> wrote:

> On 12/13/13 01:58 PM, Bill Wendling wrote:
>>
>> That’s a long laundry list of bugs there. It would be great to have them
>> fixed, but the reality of the situation is that they won’t be fixed for
>> weeks or more, if at all. And with Christmas coming up, it makes things even
>> worse. There are a few days before Phase III starts to have some progress on
>> them. But if they don’t make it, then we’ll have to release without them.
>
> How is the release schedule and blockers decided - is there a policy? As an
> open source project it seems sorta weird (to me) that rushing a release is
> more important than "getting it right" - granted if it's unlikely any fix
> date I can totally see your point..
> ---------
> (bw - You do an awesome job of being release manager and please don't take
> this as a critique - just curious)
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
----- Original Message -----

> From: "Anton Korobeynikov" <[hidden email]>
> To: "C. Bergström" <[hidden email]>
> Cc: "[hidden email] Developers" <[hidden email]>, "Mailing List" <[hidden email]>
> Sent: Friday, December 13, 2013 3:24:38 AM
> Subject: Re: [LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
>
> The usual procedure is to make time-based releases. So - "release
> trunk and make sure it's stable enough" plus - fix any outstanding
> regressions.
>
> There is some text wrt this:
> http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

Fair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem. Obviously, we cannot delay a release indefinitely, but it is completely practical to fix all of those bugs in a few weeks: they all have small test cases. I think that what we should do is put names next to as many of those as possible (to assign responsibility), and proceed under the assumption that we'll cut the final release candidate once those assigned bugs have been fixed (my guess is that there are only 5-7 underlying issues behind those various bugs I listed). There are more than enough of us that *work* on LLVM for this to be reasonable.

FWIW, when I started talking to people about using an LLVM-based compiler in production, a common response was, "how large of a code base have you compiled with it that gets the right answer?" -- and the problem has been that, when testing on multi-million-line internal codebases, miscompiles had been observed. I feel that, as a community, we should take a stronger stance against releasing code with miscompile bugs. Doing so seriously hurts our credibility. Obviously, we can't delay a release because someone somewhere feels that we miscompile something, but having small test cases is another story.

In short, I feel that going from initial branching to final release in ~1 month is a great goal, but I'd rather make it two months (as Bill points out, there are holidays in the middle) to eliminate these kinds of bugs. I think that, so long as everyone can understand what is going on, our metrics on "release blocking" bugs are clear, and our release manager observes steady progress, then delaying is preferable.

Finally, I think that very few of us that create products derived from LLVM/Clang strictly track the upstream release schedule, so I suspect that delaying for a few weeks won't affect any of our corporate contributors. Many of my colleagues say that, with gcc, they wait for the x.y.1 release before upgrading because the .0 is too buggy. But if we're not doing point releases, then I think we need tighter standards for release. Doing otherwise is not fair to our users.

Thanks again,
Hal

>
> On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström"
> <[hidden email]> wrote:
> > On 12/13/13 01:58 PM, Bill Wendling wrote:
> >>
> >> That’s a long laundry list of bugs there. It would be great to
> >> have them
> >> fixed, but the reality of the situation is that they won’t be
> >> fixed for
> >> weeks or more, if at all. And with Christmas coming up, it makes
> >> things even
> >> worse. There are a few days before Phase III starts to have some
> >> progress on
> >> them. But if they don’t make it, then we’ll have to release
> >> without them.
> >
> > How is the release schedule and blockers decided - is there a
> > policy? As an
> > open source project it seems sorta weird (to me) that rushing a
> > release is
> > more important than "getting it right" - granted if it's unlikely
> > any fix
> > date I can totally see your point..
> > ---------
> > (bw - You do an awesome job of being release manager and please
> > don't take
> > this as a critique - just curious)
> >
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State
> University
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Óscar Fuentes
Hal Finkel <[hidden email]> writes:

[snip]

> Many of my colleagues say that, with gcc, they wait for
> the x.y.1 release before upgrading because the .0 is too buggy. But if
> we're not doing point releases, then I think we need tighter standards
> for release. Doing otherwise is not fair to our users.

What happened to the LLVM/Clang maintenance release project?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Tom Stellard-3
On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote:

> Hal Finkel <[hidden email]> writes:
>
> [snip]
>
> > Many of my colleagues say that, with gcc, they wait for
> > the x.y.1 release before upgrading because the .0 is too buggy. But if
> > we're not doing point releases, then I think we need tighter standards
> > for release. Doing otherwise is not fair to our users.
>
> What happened to the LLVM/Clang maintenance release project?
>

We weren't able to make a 3.3.1 release, because we did not have enough
testers.

In order to have a successful maintenance release, we need to either:

a) Get commitments from everyone who wants a maintenance release that
they will help test the release.

or

b) Have less strict testing requirements for maintenance releases with
   the assumption that there is a lot of ongoing testing between .0 and .1
   so there are less likely to be bugs left when it is time to release .1,
   and anyone who cares about a maintenance release has had enough time to file
   bugs.

I really think maintenance releases are really important for Open Source
projects, because these projects get much more testing after a release than
before it.

I would volunteer to maintain a stable branch again after the 3.4
release, but I think we need to solve our release validation issues first.

-Tom
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

James Courtier-Dutton-4
In reply to this post by Hal Finkel
On 13 December 2013 05:24, Hal Finkel <[hidden email]> wrote:

> Bill, et al.,
>
> There are still a number of open bug reports demonstrating miscompiles on x86 with small/reduced test cases. I propose that we either delay this release until these have been fixed, or plan on a point release in the near future. I recommend that we put out another two release candidates, one at the end of this week, and one after another two weeks or so, to allow for these outstanding issues to be resolved.
>
> Specifically, I think that these issues should be resolved prior to the release of 3.4:
>
>  PR18068 [BasicAA]
>  PR18067 [GVN]
>  PR16431 (multiple; I suspect covered by the previous two)
>  PR17638 [IndVarSimplify]
>  PR18223 [IndVarSimplify]
>  PR17473 [LSR]
>  PR18165 [LSR]
>  PR16729 [Loop Vectorizer]
>  PR17288 [Loop Vectorizer]
>  PR18102 [x86 backend or CodeGen]
>  PR18000 [x86 backend or CodeGen]
>  PR17504 [x86 backend or CodeGen]
>  PR17794
>  PR17073
>  PR16108
>
>  PR18042 [LCSSA] (This hits an assert, but may miscompile with NDEBUG)
>
> Of course, the same underlying bug may be causing more than one of these, and at least some of these are already being worked on. Thoughts?
>
> Thanks again,
> Hal
>

Even if they take a long time to fix. What is the harm in adding a
test case for each one into the release 3.4 now?
It sounds to me that they are unlikely to be marked as "won't fix".
They will then come up as tests that fail and can be listed as "Known
bugs" in the release notes. Although there does not appear to be a
"Known bugs" list in the release notes at present.
Someone might even be able to use them to make an "automated compare"
that can compare them with various large projects and be able to
obtain an answer as to whether the project will compile correctly or
not with clang/llvm.

James

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
In reply to this post by Tom Stellard-3
----- Original Message -----

> From: "Tom Stellard" <[hidden email]>
> To: "Óscar Fuentes" <[hidden email]>
> Cc: [hidden email], [hidden email]
> Sent: Friday, December 13, 2013 10:24:59 AM
> Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
>
> On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote:
> > Hal Finkel <[hidden email]> writes:
> >
> > [snip]
> >
> > > Many of my colleagues say that, with gcc, they wait for
> > > the x.y.1 release before upgrading because the .0 is too buggy.
> > > But if
> > > we're not doing point releases, then I think we need tighter
> > > standards
> > > for release. Doing otherwise is not fair to our users.
> >
> > What happened to the LLVM/Clang maintenance release project?
> >
>
> We weren't able to make a 3.3.1 release, because we did not have
> enough
> testers.
>
> In order to have a successful maintenance release, we need to either:
>
> a) Get commitments from everyone who wants a maintenance release that
> they will help test the release.
>
> or
>
> b) Have less strict testing requirements for maintenance releases
> with
>    the assumption that there is a lot of ongoing testing between .0
>    and .1
>    so there are less likely to be bugs left when it is time to
>    release .1,
>    and anyone who cares about a maintenance release has had enough
>    time to file
>    bugs.
>
> I really think maintenance releases are really important for Open
> Source
> projects, because these projects get much more testing after a
> release than
> before it.
>
> I would volunteer to maintain a stable branch again after the 3.4
> release,

I would certainly also help.

> but I think we need to solve our release validation issues
> first.

To be honest, I don't think this will be a problem in practice. The amount of incremental change is small and there is already ongoing testing of all changes that go into the release (which should all be bug fixes). You may not get as much testing as for the primary release, but I suspect that many of those same people who test the base releases will also try the maintenance releases. Personally, yes, I'd contribute to testing the maintenance releases.

 -Hal

>
> -Tom
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Bill Wendling
In reply to this post by C Bergström
On Dec 12, 2013, at 11:08 PM, C. Bergström <[hidden email]> wrote:

> On 12/13/13 01:58 PM, Bill Wendling wrote:
>> That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.
> How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..

Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.

If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable. For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.

There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.

-bw


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

C Bergström
On 12/16/13 09:57 AM, Bill Wendling wrote:
> On Dec 12, 2013, at 11:08 PM, C. Bergström <[hidden email]> wrote:
>
>> On 12/13/13 01:58 PM, Bill Wendling wrote:
>>> That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.
>> How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..
> Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.
I think you're doing an awesome job and I don't disagree with anything
you've written.. curiosity killed the cat though..
>
> If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable.
I'm curious about why... release early, release often? stakeholder
pressure or just trying to maintain a predictable release schedule
>   For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.
>
> There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.
If it wasn't affecting anyone - there wouldn't be a bug report. I won't
speculate how many people that is though or the severity.. (Once again
it's not a critique or disagreeing. ALL software has bugs.. just
thinking-out-loud)
----------
I'd love to see a policy added to the Release page about who and what
constitutes a release blocker. (Something so bad that schedules be
damned that it needs to be fixed) At this point there's a 3.4 Release
branch being worked on and trunk is open for destruction... now() vs
January() who loses?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Bill Wendling
On Dec 15, 2013, at 7:10 PM, C. Bergström <[hidden email]> wrote:

On 12/16/13 09:57 AM, Bill Wendling wrote:
On Dec 12, 2013, at 11:08 PM, C. Bergström <[hidden email]> wrote:

On 12/13/13 01:58 PM, Bill Wendling wrote:
That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.
How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..
Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.
I think you're doing an awesome job and I don't disagree with anything you've written.. curiosity killed the cat though..

If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable.
I'm curious about why... release early, release often? stakeholder pressure or just trying to maintain a predictable release schedule

To have a reasonably predictable release schedule. Also to release our testers up so that they aren’t bogged down by a really long release. And we have no assurance that the bugs will be fixed, because this is all a volunteer effort.

 For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.

There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.
If it wasn't affecting anyone - there wouldn't be a bug report.

If I understand, it was an automated tool that reported some (all?) of those bugs. They test things that normal programmers don’t really do.

I won't speculate how many people that is though or the severity.. (Once again it's not a critique or disagreeing. ALL software has bugs.. just thinking-out-loud)

The reason why I said that is because some of those bugs have been in the tree for several releases now, and several large organizations have been using clang on a daily basis and haven’t ran into most of these (otherwise, they’d be fixed :-) ).

-bw


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Bill Wendling
In reply to this post by Hal Finkel
On Dec 13, 2013, at 3:30 AM, Hal Finkel <[hidden email]> wrote:

----- Original Message -----
From: "Anton Korobeynikov" <[hidden email]>
To: "C. Bergström" <[hidden email]>
Cc: "[hidden email] Developers" <[hidden email]>, "Mailing List" <[hidden email]>
Sent: Friday, December 13, 2013 3:24:38 AM
Subject: Re: [LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze

The usual procedure is to make time-based releases. So - "release
trunk and make sure it's stable enough" plus - fix any outstanding
regressions.

There is some text wrt this:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

Fair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem.

I don’t disagree with this at all.

Obviously, we cannot delay a release indefinitely, but it is completely practical to fix all of those bugs in a few weeks: they all have small test cases. I think that what we should do is put names next to as many of those as possible (to assign responsibility), and proceed under the assumption that we'll cut the final release candidate once those assigned bugs have been fixed (my guess is that there are only 5-7 underlying issues behind those various bugs I listed). There are more than enough of us that *work* on LLVM for this to be reasonable.

Those people have their own schedules and priorities. I have absolutely zero control over which bugs they give their time to. If I had someone say “I am working on this and foresee a fix by Monday,” then I would wait. But so far no one has done that.

FWIW, when I started talking to people about using an LLVM-based compiler in production, a common response was, "how large of a code base have you compiled with it that gets the right answer?" -- and the problem has been that, when testing on multi-million-line internal codebases, miscompiles had been observed. I feel that, as a community, we should take a stronger stance against releasing code with miscompile bugs. Doing so seriously hurts our credibility. Obviously, we can't delay a release because someone somewhere feels that we miscompile something, but having small test cases is another story.

In short, I feel that going from initial branching to final release in ~1 month is a great goal, but I'd rather make it two months (as Bill points out, there are holidays in the middle) to eliminate these kinds of bugs. I think that, so long as everyone can understand what is going on, our metrics on "release blocking" bugs are clear, and our release manager observes steady progress, then delaying is preferable.

Finally, I think that very few of us that create products derived from LLVM/Clang strictly track the upstream release schedule, so I suspect that delaying for a few weeks won't affect any of our corporate contributors. Many of my colleagues say that, with gcc, they wait for the x.y.1 release before upgrading because the .0 is too buggy. But if we're not doing point releases, then I think we need tighter standards for release. Doing otherwise is not fair to our users.


-bw


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
In reply to this post by Bill Wendling
----- Original Message -----

> From: "Bill Wendling" <[hidden email]>
> To: "C. Bergström" <[hidden email]>
> Cc: "Hal Finkel" <[hidden email]>, "[hidden email] Developers" <[hidden email]>, "Mailing List"
> <[hidden email]>
> Sent: Monday, December 16, 2013 3:20:48 AM
> Subject: Re: [cfe-dev] LLVM 3.4 Branch Freeze
>
> On Dec 15, 2013, at 7:10 PM, C. Bergström < [hidden email]
> > wrote:
>
>
>
>
>
> On 12/16/13 09:57 AM, Bill Wendling wrote:
>
>
> On Dec 12, 2013, at 11:08 PM, C. Bergström < [hidden email]
> > wrote:
>
>
>
> On 12/13/13 01:58 PM, Bill Wendling wrote:
>
>
> That’s a long laundry list of bugs there. It would be great to have
> them fixed, but the reality of the situation is that they won’t be
> fixed for weeks or more, if at all. And with Christmas coming up, it
> makes things even worse. There are a few days before Phase III
> starts to have some progress on them. But if they don’t make it,
> then we’ll have to release without them.
> How is the release schedule and blockers decided - is there a policy?
> As an open source project it seems sorta weird (to me) that rushing
> a release is more important than "getting it right" - granted if
> it's unlikely any fix date I can totally see your point..
> Releasing software is more of an art than a science. Any software
> release has bugs (not just our project, any project). The question
> to ask is how severe are those bugs? The balance between the
> severity and how many people are (potentially) impacted by it. Then
> you should keep in mind that we have a 6-month release cycle. So any
> bugs that aren’t fixed now will hopefully be fixed by then.
> I think you're doing an awesome job and I don't disagree with
> anything you've written.. curiosity killed the cat though..
>
>
>
> If I wait for these bugs to be fixed, we won’t be releasing until
> late January. And that’s really not acceptable.
> I'm curious about why... release early, release often? stakeholder
> pressure or just trying to maintain a predictable release schedule
>
>
>
> To have a reasonably predictable release schedule. Also to release
> our testers up so that they aren’t bogged down by a really long
> release. And we have no assurance that the bugs will be fixed,
> because this is all a volunteer effort.
>
>
>
>
>
> For those who actively use LLVM as a library, they are encouraged to
> keep current with the main trunk. For those who use the official
> release, they should be made aware of any potential major bugs they
> may come across.
>
> There is evidence to suggest that these (admittedly severe) bugs,
> some of which have been in the tree for several releases, aren’t
> affecting many people at the moment. I would love to have them
> fixed. But it’s not looking feasible at this time.
> If it wasn't affecting anyone - there wouldn't be a bug report.
>
>
> If I understand, it was an automated tool that reported some (all?)
> of those bugs. They test things that normal programmers don’t really
> do.
>

Almost all of them, and several different tools, as it turns out. Regarding whether these bugs occur in human-written code, I'd like to point out that Kay Tiong Khoo has been auditing many bugs that have been recently fixed (or hidden) by some unknown change. He's bisected a fair number of them down to fixes to other bugs. It might be interested to see how many of those were reported based on human-written code.

Regardless, I'd much rather fix a bug with a 40-line computer-generated test case, than in a million-line human-generated codebase ;)

 -Hal

>
>
> I won't speculate how many people that is though or the severity..
> (Once again it's not a critique or disagreeing. ALL software has
> bugs.. just thinking-out-loud)
>
>
> The reason why I said that is because some of those bugs have been in
> the tree for several releases now, and several large organizations
> have been using clang on a daily basis and haven’t ran into most of
> these (otherwise, they’d be fixed :-) ).
>
>
> -bw
>
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Tom Stellard-3
In reply to this post by Hal Finkel
On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote:

> ----- Original Message -----
> > From: "Tom Stellard" <[hidden email]>
> > To: "Óscar Fuentes" <[hidden email]>
> > Cc: [hidden email], [hidden email]
> > Sent: Friday, December 13, 2013 10:24:59 AM
> > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> >
> > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote:
> > > Hal Finkel <[hidden email]> writes:
> > >
> > > [snip]
> > >
> > > > Many of my colleagues say that, with gcc, they wait for
> > > > the x.y.1 release before upgrading because the .0 is too buggy.
> > > > But if
> > > > we're not doing point releases, then I think we need tighter
> > > > standards
> > > > for release. Doing otherwise is not fair to our users.
> > >
> > > What happened to the LLVM/Clang maintenance release project?
> > >
> >
> > We weren't able to make a 3.3.1 release, because we did not have
> > enough
> > testers.
> >
> > In order to have a successful maintenance release, we need to either:
> >
> > a) Get commitments from everyone who wants a maintenance release that
> > they will help test the release.
> >
> > or
> >
> > b) Have less strict testing requirements for maintenance releases
> > with
> >    the assumption that there is a lot of ongoing testing between .0
> >    and .1
> >    so there are less likely to be bugs left when it is time to
> >    release .1,
> >    and anyone who cares about a maintenance release has had enough
> >    time to file
> >    bugs.
> >
> > I really think maintenance releases are really important for Open
> > Source
> > projects, because these projects get much more testing after a
> > release than
> > before it.
> >
> > I would volunteer to maintain a stable branch again after the 3.4
> > release,
>
> I would certainly also help.
>
> > but I think we need to solve our release validation issues
> > first.
>
> To be honest, I don't think this will be a problem in practice. The amount of incremental change is small and there is already ongoing testing of all changes that go into the release (which should all be bug fixes). You may not get as much testing as for the primary release, but I suspect that many of those same people who test the base releases will also try the maintenance releases. Personally, yes, I'd contribute to testing the maintenance releases.
>

Maybe we can re-visit this after the holidays are over.  I am still
interested in doing bugfix releases for LLVM.

Besides the issue with testers the other thing we need to determine is
whether or not we want to maintain a stable ABI for the bugfix releases.
With 3.3, the plan was to have a stable ABI, but this caused me to
reject several fixes.  I would recommend relaxing this requirement
if there is are bugfix releases for 3.4, but I'd like to hear what other
people think about this.

-Tom

>  -Hal
>
> >
> > -Tom
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
----- Original Message -----

> From: "Tom Stellard" <[hidden email]>
> To: "Hal Finkel" <[hidden email]>
> Cc: [hidden email], [hidden email], "Óscar Fuentes" <[hidden email]>
> Sent: Wednesday, December 18, 2013 10:55:43 AM
> Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
>
> On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote:
> > ----- Original Message -----
> > > From: "Tom Stellard" <[hidden email]>
> > > To: "Óscar Fuentes" <[hidden email]>
> > > Cc: [hidden email], [hidden email]
> > > Sent: Friday, December 13, 2013 10:24:59 AM
> > > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> > >
> > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote:
> > > > Hal Finkel <[hidden email]> writes:
> > > >
> > > > [snip]
> > > >
> > > > > Many of my colleagues say that, with gcc, they wait for
> > > > > the x.y.1 release before upgrading because the .0 is too
> > > > > buggy.
> > > > > But if
> > > > > we're not doing point releases, then I think we need tighter
> > > > > standards
> > > > > for release. Doing otherwise is not fair to our users.
> > > >
> > > > What happened to the LLVM/Clang maintenance release project?
> > > >
> > >
> > > We weren't able to make a 3.3.1 release, because we did not have
> > > enough
> > > testers.
> > >
> > > In order to have a successful maintenance release, we need to
> > > either:
> > >
> > > a) Get commitments from everyone who wants a maintenance release
> > > that
> > > they will help test the release.
> > >
> > > or
> > >
> > > b) Have less strict testing requirements for maintenance releases
> > > with
> > >    the assumption that there is a lot of ongoing testing between
> > >    .0
> > >    and .1
> > >    so there are less likely to be bugs left when it is time to
> > >    release .1,
> > >    and anyone who cares about a maintenance release has had
> > >    enough
> > >    time to file
> > >    bugs.
> > >
> > > I really think maintenance releases are really important for Open
> > > Source
> > > projects, because these projects get much more testing after a
> > > release than
> > > before it.
> > >
> > > I would volunteer to maintain a stable branch again after the 3.4
> > > release,
> >
> > I would certainly also help.
> >
> > > but I think we need to solve our release validation issues
> > > first.
> >
> > To be honest, I don't think this will be a problem in practice. The
> > amount of incremental change is small and there is already ongoing
> > testing of all changes that go into the release (which should all
> > be bug fixes). You may not get as much testing as for the primary
> > release, but I suspect that many of those same people who test the
> > base releases will also try the maintenance releases. Personally,
> > yes, I'd contribute to testing the maintenance releases.
> >
>
> Maybe we can re-visit this after the holidays are over.  I am still
> interested in doing bugfix releases for LLVM.

Sounds good; let's do that.

>
> Besides the issue with testers the other thing we need to determine
> is
> whether or not we want to maintain a stable ABI for the bugfix
> releases.
> With 3.3, the plan was to have a stable ABI, but this caused me to
> reject several fixes.  I would recommend relaxing this requirement
> if there is are bugfix releases for 3.4, but I'd like to hear what
> other
> people think about this.

What kinds of changes were made? (can you provide a couple of examples)?

 -Hal

>
> -Tom
>
> >  -Hal
> >
> > >
> > > -Tom
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> > > _______________________________________________
> > > cfe-dev mailing list
> > > [hidden email]
> > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Tom Stellard-3
On Wed, Dec 18, 2013 at 10:57:58AM -0600, Hal Finkel wrote:

> ----- Original Message -----
> > From: "Tom Stellard" <[hidden email]>
> > To: "Hal Finkel" <[hidden email]>
> > Cc: [hidden email], [hidden email], "Óscar Fuentes" <[hidden email]>
> > Sent: Wednesday, December 18, 2013 10:55:43 AM
> > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> >
> > On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote:
> > > ----- Original Message -----
> > > > From: "Tom Stellard" <[hidden email]>
> > > > To: "Óscar Fuentes" <[hidden email]>
> > > > Cc: [hidden email], [hidden email]
> > > > Sent: Friday, December 13, 2013 10:24:59 AM
> > > > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> > > >
> > > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote:
> > > > > Hal Finkel <[hidden email]> writes:
> > > > >
> > > > > [snip]
> > > > >
> > > > > > Many of my colleagues say that, with gcc, they wait for
> > > > > > the x.y.1 release before upgrading because the .0 is too
> > > > > > buggy.
> > > > > > But if
> > > > > > we're not doing point releases, then I think we need tighter
> > > > > > standards
> > > > > > for release. Doing otherwise is not fair to our users.
> > > > >
> > > > > What happened to the LLVM/Clang maintenance release project?
> > > > >
> > > >
> > > > We weren't able to make a 3.3.1 release, because we did not have
> > > > enough
> > > > testers.
> > > >
> > > > In order to have a successful maintenance release, we need to
> > > > either:
> > > >
> > > > a) Get commitments from everyone who wants a maintenance release
> > > > that
> > > > they will help test the release.
> > > >
> > > > or
> > > >
> > > > b) Have less strict testing requirements for maintenance releases
> > > > with
> > > >    the assumption that there is a lot of ongoing testing between
> > > >    .0
> > > >    and .1
> > > >    so there are less likely to be bugs left when it is time to
> > > >    release .1,
> > > >    and anyone who cares about a maintenance release has had
> > > >    enough
> > > >    time to file
> > > >    bugs.
> > > >
> > > > I really think maintenance releases are really important for Open
> > > > Source
> > > > projects, because these projects get much more testing after a
> > > > release than
> > > > before it.
> > > >
> > > > I would volunteer to maintain a stable branch again after the 3.4
> > > > release,
> > >
> > > I would certainly also help.
> > >
> > > > but I think we need to solve our release validation issues
> > > > first.
> > >
> > > To be honest, I don't think this will be a problem in practice. The
> > > amount of incremental change is small and there is already ongoing
> > > testing of all changes that go into the release (which should all
> > > be bug fixes). You may not get as much testing as for the primary
> > > release, but I suspect that many of those same people who test the
> > > base releases will also try the maintenance releases. Personally,
> > > yes, I'd contribute to testing the maintenance releases.
> > >
> >
> > Maybe we can re-visit this after the holidays are over.  I am still
> > interested in doing bugfix releases for LLVM.
>
> Sounds good; let's do that.
>
> >
> > Besides the issue with testers the other thing we need to determine
> > is
> > whether or not we want to maintain a stable ABI for the bugfix
> > releases.
> > With 3.3, the plan was to have a stable ABI, but this caused me to
> > reject several fixes.  I would recommend relaxing this requirement
> > if there is are bugfix releases for 3.4, but I'd like to hear what
> > other
> > people think about this.
>
> What kinds of changes were made? (can you provide a couple of examples)?
>

Here are a few examples:
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018

-Tom


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Hal Finkel
----- Original Message -----

> From: "Tom Stellard" <[hidden email]>
> To: "Hal Finkel" <[hidden email]>
> Cc: [hidden email], [hidden email], "Óscar Fuentes" <[hidden email]>
> Sent: Wednesday, December 18, 2013 11:07:23 AM
> Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
>
> On Wed, Dec 18, 2013 at 10:57:58AM -0600, Hal Finkel wrote:
> > ----- Original Message -----
> > > From: "Tom Stellard" <[hidden email]>
> > > To: "Hal Finkel" <[hidden email]>
> > > Cc: [hidden email], [hidden email], "Óscar Fuentes"
> > > <[hidden email]>
> > > Sent: Wednesday, December 18, 2013 10:55:43 AM
> > > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> > >
> > > On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote:
> > > > ----- Original Message -----
> > > > > From: "Tom Stellard" <[hidden email]>
> > > > > To: "Óscar Fuentes" <[hidden email]>
> > > > > Cc: [hidden email], [hidden email]
> > > > > Sent: Friday, December 13, 2013 10:24:59 AM
> > > > > Subject: Re: [cfe-dev] [LLVMdev]  LLVM 3.4 Branch Freeze
> > > > >
> > > > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes
> > > > > wrote:
> > > > > > Hal Finkel <[hidden email]> writes:
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > > Many of my colleagues say that, with gcc, they wait for
> > > > > > > the x.y.1 release before upgrading because the .0 is too
> > > > > > > buggy.
> > > > > > > But if
> > > > > > > we're not doing point releases, then I think we need
> > > > > > > tighter
> > > > > > > standards
> > > > > > > for release. Doing otherwise is not fair to our users.
> > > > > >
> > > > > > What happened to the LLVM/Clang maintenance release
> > > > > > project?
> > > > > >
> > > > >
> > > > > We weren't able to make a 3.3.1 release, because we did not
> > > > > have
> > > > > enough
> > > > > testers.
> > > > >
> > > > > In order to have a successful maintenance release, we need to
> > > > > either:
> > > > >
> > > > > a) Get commitments from everyone who wants a maintenance
> > > > > release
> > > > > that
> > > > > they will help test the release.
> > > > >
> > > > > or
> > > > >
> > > > > b) Have less strict testing requirements for maintenance
> > > > > releases
> > > > > with
> > > > >    the assumption that there is a lot of ongoing testing
> > > > >    between
> > > > >    .0
> > > > >    and .1
> > > > >    so there are less likely to be bugs left when it is time
> > > > >    to
> > > > >    release .1,
> > > > >    and anyone who cares about a maintenance release has had
> > > > >    enough
> > > > >    time to file
> > > > >    bugs.
> > > > >
> > > > > I really think maintenance releases are really important for
> > > > > Open
> > > > > Source
> > > > > projects, because these projects get much more testing after
> > > > > a
> > > > > release than
> > > > > before it.
> > > > >
> > > > > I would volunteer to maintain a stable branch again after the
> > > > > 3.4
> > > > > release,
> > > >
> > > > I would certainly also help.
> > > >
> > > > > but I think we need to solve our release validation issues
> > > > > first.
> > > >
> > > > To be honest, I don't think this will be a problem in practice.
> > > > The
> > > > amount of incremental change is small and there is already
> > > > ongoing
> > > > testing of all changes that go into the release (which should
> > > > all
> > > > be bug fixes). You may not get as much testing as for the
> > > > primary
> > > > release, but I suspect that many of those same people who test
> > > > the
> > > > base releases will also try the maintenance releases.
> > > > Personally,
> > > > yes, I'd contribute to testing the maintenance releases.
> > > >
> > >
> > > Maybe we can re-visit this after the holidays are over.  I am
> > > still
> > > interested in doing bugfix releases for LLVM.
> >
> > Sounds good; let's do that.
> >
> > >
> > > Besides the issue with testers the other thing we need to
> > > determine
> > > is
> > > whether or not we want to maintain a stable ABI for the bugfix
> > > releases.
> > > With 3.3, the plan was to have a stable ABI, but this caused me
> > > to
> > > reject several fixes.  I would recommend relaxing this
> > > requirement
> > > if there is are bugfix releases for 3.4, but I'd like to hear
> > > what
> > > other
> > > people think about this.
> >
> > What kinds of changes were made? (can you provide a couple of
> > examples)?
> >
>
> Here are a few examples:
> http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018

I think that we should keep source compatibility, not necessarily binary compatibility, in maintenance releases. Binary compatibility, when possible, is nice, but should not stand in the way of the bug fixes themselves.

Some of the packagers should comment on this topic :)

 -Hal

>
> -Tom
>
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM 3.4 Branch Freeze

Pau Garcia i Quiles



On Thu, Dec 19, 2013 at 8:15 PM, Hal Finkel <[hidden email]> wrote:

> > > the other thing we need to determine is
> > > whether or not we want to maintain a stable ABI for the bugfix
> > > releases.
> > > With 3.3, the plan was to have a stable ABI, but this caused me
> > > to reject several fixes.  I would recommend relaxing this
> > > requirement if there is are bugfix releases for 3.4, but I'd like to hear
> > > what other people think about this.
> >
> > What kinds of changes were made? (can you provide a couple of
> > examples)?
> >
>
> Here are a few examples:
> http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018

I think that we should keep source compatibility, not necessarily binary compatibility, in maintenance releases. Binary compatibility, when possible, is nice, but should not stand in the way of the bug fixes themselves.

Some of the packagers should comment on this topic :)


Breaking ABI in patch releases with no other changes?

As a Debian packager (but not LLVM packager), I am opposed to changing ABI without bumping soversion and changing library name. If we have this:

LLVM 3.4.0 => libclang-3.4.so.1
LLVM 3.4.1 => libclang-3.4.so.1 (same)

but they are ABI-incompatible, that's going to cause trouble.

But if we have this:

LLVM 3.4.0 => libclang-3.4.so.1
LLVM 3.4.1 => libclang-3.4.so.2 (soname bumped)

that's perfectly fine

(I guess everybody here knew that already...)

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12