search for: stagnation

...c1) > 322 regressions<-- release announcement + 3weeks(rc2) > 325 regressions<-- release announcement + 4weeks > 326 regressions<-- release announcement + 5weeks(rc3) > > List of fixed bugs on rc3 release was long and impressive. Unfortunately > for regressions there is a stagnation. Regression bugs do get fixed too but "new" regressions are added at the same rate. A lot of the of the newly reported regressions happened before 1.2-rc1; it looks like people are using the release candidates to test their favorite app with and report the regression they find. And that...

...ork on lld? He developed a process in which people with significant out of tree patches were able to catch up, merge the mega patch and move forward without significant churn. I agree it is non-zero, but it is very low, and the cost seems worth the price of forward progress and avoiding perpetual stagnation. -Chris

There is a linker argument that only Apple's GCC recognizes in the latest build. In libs/wine/Makefile.in, there is a variable that reads: Code: DYLIB_LDFLAGS = -compatibility_version $(SOVERSION) -current_version $(VERSION) -headerpad_max_install_names in order for non-Apple GCC to successfully build, it needs to pass-through the argument to the linker. The line should read: Code:

On Sun, 20 May 2007, Bram Adams wrote: > Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: >> Anton is right. You should be able to use -fno-builtins to disable >> this. > > Thanks, that did the trick. > > Some final remarks (my app works again :-)): > * llvm.va_start and similar intrinsics now have an i8* arg instead > of an sbyte** ok >

On Tue, 22 May 2007 23:52:46 -0700 (PDT) Chris Lattner <sabre at nondot.org> wrote: >On Sun, 20 May 2007, Bram Adams wrote: >> On a related note: while using llvmc I have some test cases where the >> following error now pops up on Linux X86 (not on OSX): >> >> <premain>: CommandLine Error: Argument 'debug' defined more than once! >> llvmc:

On 10/30/13 08:24 AM, Richard Smith wrote: > > May I humbly propose you create a c++11-development branch > now/later/anytime and let people start using that. In parallel to > that let people know that pieces of the c++11 branch will > potentially start merging Feb 1st 2014. (roughly 3 months from > today). This gives people time to review things before they

Hi, Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: > Anton is right. You should be able to use -fno-builtins to disable > this. Thanks, that did the trick. Some final remarks (my app works again :-)): * llvm.va_start and similar intrinsics now have an i8* arg instead of an sbyte** * For some reason the Arguments of a Function are now circularly linked,

Hi, To try to bring our wiki 'up to date' (as in, no longer talking about CVS), I've gone through and rewritten a lot of the wiki content for our main landing pages: our front page, the software and specifications pages, the infrastructure pages, and even (to an extent) the mission statement. A lot of this is trying to describe how we've interpreted these things over the past ten

> On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > > > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > >

...theless due to the fact that releases are out of sync Compiz users do not get new features when KDE has a release. This gets to a real problem when KWin changes the decoration API as that causes KDE4-Window-Decorator to crash (this is the most often reported bug against KWin). This has let to a stagnation in our decoration API as we don't dare to touch the code again. Nevertheless I plan to change the API in 4.7 and our most prominent decorations (Oxygen and Aurorae) will move to it. Now with the git transition there might be a solution for these kind of problems: Compiz's KDE Plasma in...

On Tue, Oct 29, 2013 at 6:11 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote: > On 10/30/13 03:17 AM, Chandler Carruth wrote: > >> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto: >> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote: >> >> On 10/29/13 07:27 AM,

On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> This will also greatly facilitate certain measurements I'd like to do >

On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev < >> llvm-dev at

> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> >> On Tue, Dec 13, 2016 at 9:28 AM, Mehdi

> On Feb 19, 2019, at 7:43 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote: >> On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Regarding a plan for conversion, I'm keen to avoid perfect

On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

Lucian, So far here is the best we could find out: https://bugzilla.redhat.com/show_bug.cgi?id=1084747 Testing to see if this is the solution; so far it seems to be. Cheers, Boris. On Tue, Jan 13, 2015 at 2:49 PM, Nux! <nux at li.nux.ro> wrote: > Use BIND. How the times have changed. :-) > > PS: I'm also curious for a solution.. for when djbnostalgia hits me. > >

...place where we are afraid of doing sweeping changes that make the codebase better. It is important to continually reinvest in the health of the codebase, and it isn’t bad to incentivize people to merge their changes upstream. Being overwhelmingly afraid of ‘breaking history’ is a path that leads stagnation and ultimate replacement by newer technologies. There are many other projects that have suffered this fate, usually for a combination of reasons including things like this. -Chris

On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev < >> llvm-dev at

On 10/30/13 03:17 AM, Chandler Carruth wrote: > On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > On 10/29/13 07:27 AM, Chandler Carruth wrote: > > On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" > <cbergstrom at pathscale.com