Re: clang and FSF's strategy
e...@thyrsus.com (Eric S. Raymond) writes: > David Kastrup's recent question on emacs-devel motivates me to bring > up a larger related question I've been meaning to open for a while: > Are the FSF's goals best served by continuing to technically restrict > GCC? I don't think that's even a sensible question. The point of the GPL is to promote expansion of Free Software, and the tool it uses for doing so is by covering licensing of "the work as a whole". When providing full technical capabilities for accessing the functionality of of program without creating a larger whole in the process, we are basically down to the LGPL. So most definitely the FSF's goals are best served by continuing to technically restrict GCC. If there is any question, the question is rather _what_ restrictions serve its interests more than it impedes them. Since any lifted restrictions cannot easily be reinstated, it makes sense to be conservative. > This is a question in which I have some positive stake. Yes, I > continue to be opposed to the FSF's style of propaganda exactly > because I think it hinders an end goal - a software ecosystem that is > open-source and user-controlled - that I agree with and have worked > hard to achieve. You are crossposting to two public project lists of the GNU project with inflammatory language and mischaracterizations. You have been involved with the GNU project long enough to be well aware that this kind of crowbar approach does not lead to much more than headlines about Free Software infighting. > The clang developers very carefully do *not* say that they aim to make > GCC obsolete and relegate it to the dustbin of discarded tech. Like most Free Software, GCC started out in a state where its technical competitiveness placed it in the dustbin. And that's a state the GNU project prefers over that of it being an enabling and seminal part of proprietary software "ecosystems". That's the reason GNU software is licensed under copyleft rather than permissive licenses, and the criterion of popularity should not render that choice irrelevant. There is leeway for making and balancing individual decisions according to individual tradeoffs. Your black-and-white and all-or-nothing rhetoric and confrontational style is not helpful for that. > Therefore, I point out that FSF can no longer prevent proprietary > vendors from plugging into a free compiler to improve their tools. And we could not prevent proprietary vendors from plugging into proprietary compilers to improve their tools, either. And things like Microsoft Visual C++ and the Intel compilers are quite competitive in technical respects. The only thing we ever have been able to prevent people to do is them plugging into _our_ free compiler. > That horse has left the barn; Lots of horses have left the barn. That's irrelevant as long as it is not the horse we are sitting on. > I also think it bears noticing that nobody outside of Microsoft seems > to particularly want to write proprietary compilers any more. Huh? Intel still writes proprietary compilers, basically every GPU vendor boosts his own proprietary compiler. > In some sense I don't really care who wins. Either GCC or clang will > serve my needs. I do prefer that both tools be as excellent as > possible. And it would be nice if the FSF were to demonstrate that it > can recognize changed conditions and move with the times. The whole point of the FSF was _not_ to "move with the times". If you would be willing to forego your popularity contest based approach, you might have a better chance of getting actual adjustments in the details. But at the core level, I see a fundamental miscomprehension about the contexts in which strong copyleft and the GNU project operate and make sense. As long as you don't come to terms with that, I don't see this discussion leading anywhere. And that's not even taking into account that key players tend to be less than amused about such a confrontational approach. -- David Kastrup
Re: clang and FSF's strategy
"Eric S. Raymond" writes: > Ian Lance Taylor : >> I'm sympathetic to our comments regarding GCC vs. clang. But I'm not >> sure I grasp your proposed solution. GCC does support plugins, and >> has supported them for a few releases now. > > Then I don't understand why David Kastrup's question was even > controversial. I must have missed the controversy. > If I have failed to understand the background facts, I apologize and > welcome being corrected. I'll refrain from any comments about wiping the egcs off anybody's face. My reply to your "call to arms" was actually rooted in as much (or rather little) actual knowledge of the pertinent situation as your request appears to have been. But as you chose an enquiring mail of mine to justify your confrontational approach, I felt that I should mitigate the damage purportedly originating from me by addressing those points that I cannot consider a justifiable conclusion from what I wrote. -- David Kastrup
Re: clang and FSF's strategy
Michael Witten writes: > On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote: > >> The fact that these non-free tools are not based on gcc are a >> testament to how proprietary software developers cannot plug into gcc, >> and how clang is fostering non-free software. > > What does it matter whether clang fosters non-free software if clang *also* > fosters free software? Indeed, non-free software inspires a lot of free > software, anyway. > > Apparently, gcc isn't fostering much of anything, except for a desire to > replace it with llvm/clang. > > Where there is the least friction, there is the most freedom. And you can save a lot of money on street construction if everybody just drives off-road. Simple solutions for the win. The GNU project did not get where it is by accident. If you take a look at "prisoner's dilemma" tournaments, by far the most successful strategy invariably is "tit for tat" and slight variations. The unmodified strategy will _never_ beat an opponent in any single battle, and it still emerges as the winner in many tournaments. At any rate, if you want to bash the strategies of the GNU project, these lists are the wrong place to go. Try doing it on the Clang list though I am skeptical that they do not have better things to do as well. -- David Kastrup
Re: clang and FSF's strategy
David Kastrup writes: > e...@thyrsus.com (Eric S. Raymond) writes: > >> David Kastrup's recent question on emacs-devel motivates me to bring >> up a larger related question I've been meaning to open for a while: >> Are the FSF's goals best served by continuing to technically restrict >> GCC? >> This is a question in which I have some positive stake. Yes, I >> continue to be opposed to the FSF's style of propaganda exactly >> because I think it hinders an end goal - a software ecosystem that is >> open-source and user-controlled - that I agree with and have worked >> hard to achieve. > > You are crossposting to two public project lists of the GNU project > with inflammatory language and mischaracterizations. You have been > involved with the GNU project long enough to be well aware that this > kind of crowbar approach does not lead to much more than headlines > about Free Software infighting. And just for the record, here are some of the headlines. http://lwn.net/Articles/582242/> I'm keeping the crosspost since the main issue started up on emacs-devel, and it mostly pertains to gcc-devel where some participants may be interested in using the opportunity to correct misconceptions in the discussion following the article (which could have been a lot worse I guess). With regard to the discussion on the mailing lists itself, I think that pretty much everything that's relevant to the big rhetorics has been said already. That does not mean that nothing remains to be done in the area of better integrating Emacs and GCC, but it does not appear like the main obstacles are of the kind that can be overcome by swashbuckling. -- David Kastrup
Internal abort call optimization?
Hi, I reported a problem I have with abort to the glibc bug tracker at http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might provide some reading material. Anyway, it has been pointed out to me that the requested change would not accomplish much anyway since GCC has its own builtin notion of the abort function. So here is my beef with the current way abort calls get optimized: basically it boils down to the interaction of -fcrossjumping (enabled with -O2) and the noreturn attribute of abort. The combination of both optimizations means that usually only one abort call will actually get compiled into a compilation unit, and all calls will instead jump there without bothering to clean the stack (after all, it is a noreturn function). This is egregiously bad when using the generated coredump (abort triggers SIGABRT) for debugging failed assertions or other aborts: neither the call/return location is correctly associated with the source code, nor is the stack/register state interpretable using debugging info. Given that the distinguishing feature of abort over exit is the creation of a core dump, it would be good if this core dump would actually be useful. I know several people who have spent days debugging at the wrong place, including myself. Currently Emacs contains in etc/DEBUG the instructions ** When you are trying to analyze failed assertions, it will be essential to compile Emacs either completely without optimizations or at least (when using GCC) with the -fno-crossjumping option. Failure to do so may make the compiler recycle the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. However, the problem is obviously not restricted to Emacs. If the "noreturn" attribute for the internal abort were removed, at least only abort calls with compatible stack frame and the same (tentative) followup code would get folded. That would avoid the worst head-scratchers when trying to figure out what went wrong. Probably better would be to just disable the crossjumping optimization for calls of abort. Maybe this would warrant a new attribute. Thanks for caring, -- David Kastrup
Re: Internal abort call optimization?
"Daniel Berlin" <[EMAIL PROTECTED]> writes: > You are about 3 years late to the party on this one :) > > http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html Yup. > Realistically, you are not going to be able to get good stacktraces > with optimized code for *other* reasons, abort is just the first thing > you hit. Oh, we are not talking about "not good stacktraces" here. We are talking about "completely different location, possibly even in a different function, and debug info that has nothing to do with the actual state of the stack frame". "Not good" is expected with optimization. "Catastrophically misleading" is a different category. Since one of the main points of "abort" _is_ the stack trace, that's a particularly bad function call to optimize in this manner. Omitting either the -fcrossjumping _or_ the noreturn optimizations would get this back into the "expected consequence of optimization on debugging" scale. It is the combination of them that makes it impossible for the debugger to figure out the current call situation and temporary variable/register/stackframe assignments. > You are much better off making an abort that gives you more correct > info (see, for example gcc's fancy_abort) than trying to take the info > you get at some random point in an optimized program, and then trying > to build it into something useful for the user (as abort does). But fancy_abort does not help in examining variables: they may be sitting on the stack or in registers. Without noreturn optimizations, at least the compiler would only crossjump to abort calls with equal continuation and equal data locations, so examining variables is still possible in the debugger and one can get a good guess at where one is currently. And without crossjumping, the debugging info might tell the debugger just how garbled the current data locations are. But with both active, stack data and return addresses are garbage. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: [PATCH] gc --aggressive: make it really aggressive
Johannes Schindelin <[EMAIL PROTECTED]> writes: > However, I think that --aggressive should be aggressive, and if you > decide to run it on a machine which lacks the muscle to be aggressive, > well, you should have known better. That's a rather cheap shot. "you should have known better" than expecting to be able to use a documented command and option because the git developers happened to have a nicer machine... _How_ is one supposed to have known better? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Git and GCC
Junio C Hamano <[EMAIL PROTECTED]> writes: > Junio C Hamano <[EMAIL PROTECTED]> writes: > >> Jon Loeliger <[EMAIL PROTECTED]> writes: >> >>> I'd like to learn more about that. Can someone point me to >>> either more documentation on it? In the absence of that, >>> perhaps a pointer to the source code that implements it? >> >> See Documentation/technical/pack-heuristics.txt, > > A somewhat funny thing about this is ... > > $ git show --stat --summary b116b297 > commit b116b297a80b54632256eb89dd22ea2b140de622 > Author: Jon Loeliger <[EMAIL PROTECTED]> > Date: Thu Mar 2 19:19:29 2006 -0600 > > Added Packing Heursitics IRC writeup. Ah, fishing for compliments. The cookie baking season... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Something is broken in repack
Nicolas Pitre <[EMAIL PROTECTED]> writes: > Well... This is weird. > > It seems that memory fragmentation is really really killing us here. > The fact that the Google allocator did manage to waste quite less memory > is a good indicator already. Maybe an malloc/free/mmap wrapper that records the requested sizes and alloc/free order and dumps them to file so that one can make a compact git-free standalone test case for the glibc maintainers might be a good thing. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Something is broken in repack
Wolfram Gloger <[EMAIL PROTECTED]> writes:
> Hi,
>
>> Note that delta following involves patterns something like
>>
>>allocate (small) space for delta
>>for i in (1..depth) {
>> allocate large space for base
>> allocate large space for result
>> .. apply delta ..
>> free large space for base
>> free small space for delta
>>}
>>
>> so if you have some stupid heap algorithm that doesn't try to merge and
>> re-use free'd spaces very aggressively (because that takes CPU time!),
>
> ptmalloc2 (in glibc) _per arena_ is basically best-fit. This is the
> best known general strategy,
Uh what? Someone crank out his copy of "The Art of Computer
Programming", I think volume 1. Best fit is known (analyzed and proven
and documented decades ago) to be one of the worst strategies for memory
allocation. Exactly because it leads to huge fragmentation problems.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
