search for: stagnat

...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 th...

...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:

...es where the > following error now pops up on Linux X86 (not on OSX): > > <premain>: CommandLine Error: Argument 'debug' defined more than once! > llvmc: CommandLine Error: Argument 'debug' defined more than once! No idea. :) llvmc is a work in progress which has stagnated somewhat. I strongly recommend using llvm-gcc directly. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...error now pops up on Linux X86 (not on OSX): >> >> <premain>: CommandLine Error: Argument 'debug' defined more than once! >> llvmc: CommandLine Error: Argument 'debug' defined more than once! > >No idea. :) > >llvmc is a work in progress which has stagnated somewhat. I strongly >recommend using llvm-gcc directly. Bram: About the only way I know of to get that error is if you linked LLVM into a loadable module and loaded it with llvmc. Did you do that? If so, don't link any LLVM stuff into your module! See the Makefile in the "Hello&q...

...release-after-next using more modern toolchains and > is *hopefully* a win-win in your view. > > > I don't see how this helps anything. We don't /want/ to have the > hassle of some people developing on a branch and some on trunk, so we > would essentially have trunk stagnating and everyone developing on the > branch. And then we'd merge the branch back again. Net result: exactly > the same as if the people who aren't ready for c++11 stick with the > 3.4 release. No its entirely not the same 1) Branch development is very common - I can't imagin...

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

...spent almost two years on the old LLD and 1.5 years on the new LLD, I can say that Rafael's stance on focusing on making a good linker first really makes sense. I can easily imagine that if we didn't focus on that, we couldn't make this much progress over the past 1.5 year and would be stagnated at a very basic level. Do you know if I'm a person who worked really hard on the old (and probably "modular" whatever it means) linker so hard? I'm speaking based on the experience. If you have an concrete idea how to construct a linker from smaller modules, please tell me. I s...

...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...

...hurt > your target of the release-after-next using more modern toolchains and is > *hopefully* a win-win in your view. I don't see how this helps anything. We don't /want/ to have the hassle of some people developing on a branch and some on trunk, so we would essentially have trunk stagnating and everyone developing on the branch. And then we'd merge the branch back again. Net result: exactly the same as if the people who aren't ready for c++11 stick with the 3.4 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

...spent almost two years on the old LLD and 1.5 years on the new LLD, I can say that Rafael's stance on focusing on making a good linker first really makes sense. I can easily imagine that if we didn't focus on that, we couldn't make this much progress over the past 1.5 year and would be stagnated at a very basic level. Do you know if I'm a person who worked really hard on the old (and probably "modular" whatever it means) linker so hard? I'm speaking based on the experience. If you have an concrete idea how to construct a linker from smaller modules, please tell me. I s...

...wo years on the old LLD and 1.5 years on the new LLD, I can say > that Rafael's stance on focusing on making a good linker first really makes > sense. I can easily imagine that if we didn't focus on that, we couldn't > make this much progress over the past 1.5 year and would be stagnated at a > very basic level. Do you know if I'm a person who worked really hard on the > old (and probably "modular" whatever it means) linker so hard? I'm speaking > based on the experience. If you have an concrete idea how to construct a > linker from smaller modules,...

...spent almost two years on the old LLD and 1.5 years on the new LLD, I can say that Rafael's stance on focusing on making a good linker first really makes sense. I can easily imagine that if we didn't focus on that, we couldn't make this much progress over the past 1.5 year and would be stagnated at a very basic level. Do you know if I'm a person who worked really hard on the old (and probably "modular" whatever it means) linker so hard? I'm speaking based on the experience. If you have an concrete idea how to construct a linker from smaller modules, please tell me. I s...

...nderstand that there is still controversy about whether making a change would improve the project, I just wanted to point out that if we converge on that, then we should consider what LLVM looks like 10 years from now, not just what it looks like 6 months from now. I for one don’t want to see LLVM stagnate, slow, and suffer because of legacy concerns. -Chris

...the old LLD and 1.5 years on the new LLD, I can say >> that Rafael's stance on focusing on making a good linker first really makes >> sense. I can easily imagine that if we didn't focus on that, we couldn't >> make this much progress over the past 1.5 year and would be stagnated at a >> very basic level. Do you know if I'm a person who worked really hard on the >> old (and probably "modular" whatever it means) linker so hard? I'm speaking >> based on the experience. If you have an concrete idea how to construct a >> linker from s...

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

...wo years on the old LLD and 1.5 years on the new LLD, I can say > that Rafael's stance on focusing on making a good linker first really makes > sense. I can easily imagine that if we didn't focus on that, we couldn't > make this much progress over the past 1.5 year and would be stagnated at a > very basic level. Do you know if I'm a person who worked really hard on the > old (and probably "modular" whatever it means) linker so hard? I'm speaking > based on the experience. If you have an concrete idea how to construct a > linker from smaller modules,...

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