Slashdot Mirror
GCC 2.95 Released
sparky writes "The GNU Compiler Collection (GCC) 2.95 is available ."> here [Ed: Please use a mirror]. This is the first release of GCC since the EGCS steering committee took over, and a major step on the way to GCC 3.0. " Interesting to see we have a new ANC (acronym name change).
Face it. Aliasing problems will always be a problem with C/C++, and in general, any language which relies so heavily on pointers. There are alternatives. All of them are unrealisitic for the kernel due to political and cultural considerations. For example, Ada is one of the best languages for systems programming because of its speed and ability to safely offer fine control over bit-twiddling and low-level operations. A Linux kernel rewritten in Ada would be awesome and damn near bullet proof. But it will never happen.
If I understand the situation correctly, pgcc is basically a set of patches against egcs/gcc. A lot of the code from pgcc should make its way into gcc eventually, although I believe that some parts can't be included, such as those written by Intel. That's because the copyright for changes to GCC must be assigned to the FSF, and Intel seems unwilling to do so.
"Oh, your 2.2 kernel crashed. Did you compile it with egcs?"
:-/
That is a common question on linux-kernel. Yes, the code was cleaned up in this respect. But nevertheless, noone guarantees you that an egcs compiled kernel will work. I still use gcc 2.7.2.3 on production boxes for kernel compiles.
The difference between egcs and gcc 2.95 is that Mark's aliasing framework is turned on by default. There have been some heavy debates about this on the kernel mailing list and apparently the communication between the egcs team and Linus was not very successful
I stand corrected then; than you for the information.
pump seems fine here. why do you suggest this?
-matt
Until a better answer comes up, it's a technical language (once) used in the telecommunications sector. Here is a site, it is in English, although the server is in Germany. Hope it helps for a start. CHILL
Would there be any issues with Stampede Linux (or RedHat, etc) building the binaries in their distro with Code Fusion?
'Course, they couldn't distribute Code Fusion itself, but if it is fully compatible with gcc-2.95, that wouldn't seem to be much of a problem. Just that binaries the user compiles themself won't be as fast.
-Tom
Trust me. I *understand* O-O. C++ isn't even close to appealing. There are *so many* O-O languages that are better than C++, the fact that anyone uses it at all is amazing.
What are C++'s advantages over Eiffel? Over Ada95? I can think of exactly one: backward compatibility with C (and, in fact, many people who call themselves C++ programmers don't know anything about C++; thet just use a C++ compiler on their C code), and that's more of a burden than a blessing. Programming languages really *have* come a long way in the past three decades. But everyone insists on using the worst possible languages: Fortran, C, C++. Lame, lame, lame.
At the time someone announced the availability of gcc 2.95 at the GNU mirrors, it WASN'T available at the EGCS ftp site, nor their site was showing that gcc 2.95 is the actual release. If you checked the EGCS ftp site, the archives were without read access. Stop publishing this sort of notices. First because this is for freshmeat and second because it was OFICIALLY released later. Too bad a bug wasn't discovered before Cygnus release gcc 2.95.
That's pretty harsh.
On the other hand, it IS true that there is a learning curve to STL, and once you get to the top of that curve, it becomes quite a bit easier to use STL than to make your own versions of everything, because it is really likely that the STL list class, for instance, is more flexible, more robust, and more efficient than the list that you would write in 30 minutes or an hour. While it probably won't be as intuitive for you at first, a little perserverence is all it takes. For a good STL starting point, check out SGI's documentation. It's pretty good.
To keep this at least somewhat relevant, I think that despite all of the language-theory arguments against C++, STL and the extremely wide support of C++ practically everywhere make it really useful to know. Is it the best language possible? No. Is it the best language right now? Depends on who you are and what you want to do.
<ASIDE>
Someone in this thread mentioned hash maps losing data- sounds very much like a comparator problem. Whoever had that problem should make SURE that the hash map has a working comparator. In my experience, 95% of hash map problems turn out to be a broken comparator.
To see if that's the case, you can check to see what's in your hash map with a simple snip of code. Assuming you've typedef'ed your hash map's type as "hash_type":
hash_type::iterator i = hash.begin();
while (i != hash.end())
{
cout << "Key: " << *i.first() << endl;
cout << "Value: " << *i.second() << endl;
i++;
}
</ASIDE>
-jacob
I agree that the utility of both Swing and STL are hindered by their sometimes awkward syntax. Those two pieces of technology in particular really make me tend to think that the "language of the future" will use first-class functions. After all, Swing's anonymous interface-implementors are just make-believe first-class functions, and the same is true of the function-objects that you have to use in STL. It seems that both of those areas highlight the fact that if you want to have a useful collection of generalized data, you sometimes need to be able to plug in an arbitrary algorithm just as much as you need to be able to plug in an arbitrary datum. From there, first-class functions are a short step. They'd go a long way towards cleaning up the mess that STL (and Swing too, to a lesser extent) can sometimes be.
On the other hand- STL is STILL easier than the alternative, writing your own hash table for every new data type you need to keep in a hash and every possible key you could store that data with. Digging through levels of templates is bad, but you probably don't have to if you want to debug an STL class: in all of my experience with STL, I have never found a serious bug that didn't ultimately turn out to be my own fault. For example, I have certainly had my fair share of data-losing hash maps, and I've learned that you should always look extremely closely at your comparator before you start scouring the STL code and cursing about the library programmers and how they somehow released a hash table that randomly loses data (though I freely admit to jumping directly to step 2 myself- it makes it all the more humiliating later when somebody points out that I'm using '=' instead of '==' or something =]).
-jacob
> Because you can only write an emulation of currying with much template hacking and trouble,
:-)
> should I conclude that it is far inferior to functional programming languages
Yes!
ML will rule the world! you'll see.
-mcpu=k6 and -march=k6 are new in gcc 2.95
Linus is a great guy and all that. But he has some blind spots. Among them are Quality and Engineering issues. He just does not have the background or experience to make good judgements in these areas. He lacks a humility which would tell him that he is not an expert in all areas of computer science. What we are starting to see is that his lack of expertise in some areas has hindered Linux's ability to scale well across architectural and performance bounderies. In other words, the kernel is becoming more and more complex and Linus is unfamiliar with the technologies which could address these issues. And worst of all, he appears to be unwilling to learn.
I'd recommend browsing Slashdot with Lynx and using Emacs or some other
such editor to edit text inputs. It's all very sweet because using an
external editor makes it so much easier to run ispell.
"C++ and other OO languages have been proven to be more efficient for programmers on projects larger than 100k lines."
You forgot to provide a link to this "proof" or any cites. Please provide sufficient details for us to determine how loosely you use the word "proof".
Guess what's funnier... you just proved his point. The most pathetic thing here is your apparent lack of intellect, rationality, and ability to be objective. Furthermore, why can't cretins of your ilk ever spell?
Stop watching Star Trek and leave the house for a change!
Anonymous Spanker
For most projects, switching to C++ would probably be less of a benefit than writing the *C* code correctly. :-/ Programming in an object-oriented language is sometimes useful..many benefits (including interfaces) of object-orientation, however, can be had in a non-OO language with little or no trouble. Only inheritance is hard to emulate.
The other thing about C++ is the STL. Don't even make me talk about the STL, I just tried to use it in a program and I'm now trying to remove all references to it..it's baroque, buggy, and poorly defined. For starters. (among other things -- my hash tables keep 'forgetting' about entries. I insert an entry with key "foo" into the table. Shortly afterward, I try to extract the entry from the table. Surprise! It's not there! Argh... Oh, and the default hash function knows about char *s, but the default hash EQUALITY routine just compares addresses!!)
Daniel
If Java isn't object-oriented I don't even wanna try Smalltalk. I don't think making everything OO is a good thing. Doing even simple things in Java can be a pain because of the forced OO-style. C++ is much better.
Egcs works with libc5 / 2.0.x. I don't know about the new GCC but I think I'll try.
It's great to see the full span of history, here. The previous article was Ritchie releaseing code for the first C compilers and this one is GCC 2.95 which is the culmination of at least 15 years of work on the part of Stallman, FSF, Cygnus and probably tens of thousands of volunteers. For those who are looking to advocate Open Source within their companies, or just see for yourself what this "new" paradigm can produce, please read the GCC source! It's some of the best code I've ever seen (though I admit it has it's... blemishes). The way it achives platform neutrality while producing highly platform-optimizied code is genius, and you can really feel its roots (the intermediate language is a compromise between Stallman's love for LISP and a desire to keep compilation fast and efficient). This is all without going into the fact that there are now front-ends for every major programming language with the exception of the purely interpreted ones (Perl, Python, TCL, etc).
Currently, as far as I am aware, this is the finest compiler on the face of the Earth, and I dare someone to prove it wrong. There are compilers that produce faster code for a specific platform, and there are compilers for languages that GCC has never heard of, but GCC wins the all-around best technology (IMHO) for producing native instructions from your pet language. It's the one tool which I feel justifies all of Stallman's quirkiness, and gives me faith in the future of Open Source.
I think some of the source changes in pgcc rendered gcc pentium-only but most of them are in the main source tree of egcs. If you're only using pentium, the latest pgcc will probably be better.
Shouldn't it be trivial (with ispell's "-a" mode) to write a web-based interface to integrate with things like Slash?
Speed is one thing, but last time I checked only egcs/gcc had threadsafe exception handling.
Anything change in the last year?
A compiler that produces non-threadsafe code is of no use to me.
Are you saying that you think Microsoft has the same level of respect and admiration among their customers that they had in, say, 1993? They've been in a decline since about 1995--I maintain that they peaked at about the release of Win95, and have been on a downward trajectory ever since. Oh, it was slow at first, manifested in small ways, but it's accelerating every day. No, it hasn't been reflected in their stock prices or earnings yet, but that's only a matter of time. You can't keep customers forever when everyone thinks you are scum.
Yea, new compiler. But, it would help if more projects would make the change to C++.
FunOne
FunOne
I applaud the fact that you didn't just blindly flame what you do not know. I would suggest that you learn a bit about it--who knows, you might like it!
If anyone has gotten it to build on Linuxppc could you e-mail me and let me know if you had any problems, and how to get around them.
Yes ANSI standards exist. If you know of anyone who's ever shipped software and been able to use nothing but ANSI C/C++ I'd like to hear about it.
And no, Unix isn't really ANSI, because you're programming to an operating system, and even POSIX unices are different enough that you end up with ifdefs.
Anyone know how backward compatible gcc 3.0 is gonna be with say, libc5 and 2.0.x? I have systems that haven't been upgraded to glibc2/2.2.x/egcs etc yet... or is 2.7.2.3 still going to be the recommended version for non-cutting edge machines? I'm sure there's a lot more boxes out there than just mine that have gcc 2.7 for 2.0.x and similiar compatibility, after all.
David
This sig left intentionally blank.
Is there any indication from any Important People(tm) when this bug in the kernel will be patched?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
If you're up this late on Friday night reading slashdot, you needn't use a mirror. I just downloaded the whole thing at about 300k/s straight from ftp.gnu.org. :)
Hit the egcs mailing list archives off of the
egcs homepage. There is a long, long collection
of threads about this problem, dealing especially
with the Linux kernel. Linus Himself[tm] gets
heavily involved.
Parts of it turn into a flamefest, but there
/is/ a good deal of information down in there as
well.
In any case, it's not a showstopping bug; you
just have to use a flag.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
If you're on redhat 6, don't use pump. Update to the latest version of dhcpcd, and modify the ifup scripts to invoke dhcpcd with a -h command line parameter instead of pump.
+ This is probably because of the lack of
+ precompiled headers. Much of the source
+ includes the headers to libs and system stuff.
Most probably. Without optimization, by far the
bulk of a compiler's time is spent parsing.
Without meaning to sound condescending, I must
at this point mention things like the redundant
include guards described in the Lakos text. I
found that the little extra typing really can
speed up the compliation stage significantly.
+ 4 Meg executable swells to a mindboggling
+ 130MB of god-knows-what nonsense when the
+ -g flag is on.
Speaking only for myself, not the EGCS people:
why do you care? It's the debugging version,
not the production version.
I realize that's harsh, but for the most part
my binary sizes don't get much attention from
me until after I turn off -g, enable a string
of space-saving optimizations, and then strip
the binary.
+ the current situation sucks for those of us
+ with beefy apps.
My last major project was beefy enough, and
egcs pulled through with flying colors for me.
If you have suggestions, I'm sure the EGCS
maintainers would welcome your patch...
Luck++;
Phil
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I used to be anti-STL until I was forced into
using it. Now I believe it is totally optimal for
what we are doing (manipulating many large data
sets generated from a numerical engine).
One reason I was against it initially is that it
requires a very standards compliant C++ to work
properly. Honestly I've been using the M$
compilier which is pretty compliant, but is
missing partial specialization which would make
iterator_traits work correctly.
Also I have found that use of STL's generic
programming paradigm, if bought into permeates
your code beyond the use of collections. For
instance I find myself doing this all the time
class foo{
template
void bar(It begin, It end);
};
Unfortunately MS forces you to define bar inline
in this situation, but it works...
Generally STL == good
Negatives:
compilies very slow
Bloats object code.
Anyway I'm intested in getting my hands on the
latest GCC to start attempting to compile some
of the STL code I have been working on.
C++ is not OO, it's multi-paradigm.
It means that it supports the combined use of classic low-level structured programming (C), object-oriented programming (Simula), and template programming / stronger typing (Ada).
SmallTalk is 100% pure Object. Java is around 75%.
Now, my opinion: C++ is overcomplicated, mostly because it is too low level and high level at the same time.
Because I wan't my compiler to be faster than VC++, it's a test of manhood.
Compile kernel 2.0 only with gcc 2.7.2; compile kernel 2.2 with -fno-strict-aliasing enabled as a CFLAG in arch/i386/Makefile, and you'll need to edit the configure script for glibc2.1.1 to get that working (and, of course, you need to set CFLAGS=-fno-strict-aliasing with this as well)
I ate something that disagreed with me. Maybe I should have cooked him first.
Ever notice than when compiling nbench with a bootstrapped egcs and -march=i686 you get an outrageous result for neural net? Is there some way to get the Pentium II optimization without breaking nbench?
AFAIK a linux kernel written in Ada would never get up to the complexity level of Minix, because all the coders would get fed up.
-- The act of censorship is always worse than whatever is being censored. Always.
This ain't a beauty contest. The faster the code it produces, the better it is. So no, GCC is not the finest compiler on earth, not by a long shot.
Effectively, M3 was a "one group" implementation, a Modula family language produced by DEC.
It appears to be about as portable as GCC, and the SPIN OS is written in it.
I could imagine worse ideas than trying to build a kernel in Modula 3...
If you're not part of the solution, you're part of the precipitate.
I write and maintain test software for a large
product line. Our enviroment has been defined
as ANSI C. With the number of developers on two
continents working in the code, that we have,
standards are critical. Resently we have been
running into difficulties. To solve them we have
been implimenting some OOP concept in regulare
old ANSI C. Monday I will be submiting even more
changes in that direction to my team for review.
For some tasks OOP is the only way to go. We will
eventualy be migrating to C++. Having the path to
OOP that C++ provides will make my job much easier.
Saying that C++ is trash is silly, and demonstrates
a very myoptic view of programing. As with all
languages, there are "features" that should be
avoided. But data hiding and single inheretance
are incredably valuble. Especially in instrument
control.
I don't mean to be a jerk, trust me.
But if you have to ask that question, you need to learn a whole lot more about how gnu compliant software works. You need to know more about software, period.
Configure is a brilliant hack that determines what sort of machine software is being compiled for. You don't want to compile a new libc and attempt to install it unless you know EXACTLY what the hell you're doing. It's the heart and soul (next to your kernel) of the whole machine. Break it, and you won't boot.
Leave it alone. If you need a new libc at your point of development, get a new distro on cd, and reinstall.
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
The reason that I care that the executable grows to 130MB is that I HAVE TO WAIT FOR IT TO LINK!
I guess I am spoiled by 30 second turn arround times on other platforms to link my app but 8-10 minutes to make a small change in one file and launch the debuger is way beyond unacceptable.
--BQ
When compiling 2.3.12 (the latest dev series kernel), I went to add the -fno-strict-aliasing but found that the makefile already tested if the compiler supports this and was adding itself. - So no edit needed.
>Also it allows you to dynamically (ie at runtime) interject a class in your hierarchy
How is this of value? Deep inheritence
heriarchies are evil enough. I can't imagine
wanting deepen them at run time. Sounds like
a maintence nightmare to me.
installwatch
gnome rpm work station
I could list more....just go to www.freshmeat.net and search for rpm.
"Gravity must be scholastic occult quality or the effect of a miracle."
You can't get RPM's for this yet, it's just been released! You'll be able to get them when someone makes them, and you'll surely be able to get them at the Rufus RPM Repository. In the mean time, you can try compiling it yourself from the released source. Even better, you can make your own RPM of it, go to RPM.org to learn how (Maximum RPM is a great book).
----
----
Open mind, insert foot.
I wonder how many other programs will show this same problem. I would be very surprised if the Linux kernel is the only thing which has aliasing problems.
Will it be necessary to rebuild glibc2.1.1 after upgrading to gcc2.95, or should the glibc I built with egcs1.1 continue to work?
because I say so. I did not post the original
comment, but I agree with it.
..then buy yourself a compiler you like. Or write one. ;)
<^>_<(ô ô)>_<^>
Hey, just ran a benchmark on the binaries in different areas comparing pgcc to gcc 2.95 using the hwinfo2html program (http://rob.current.nu) and compiler flags "-O9 -mpentium -ffast-math". I found that pgcc has a slight edge in performence at this stage, but not by a noticable amount. Have a look here . Most interesting are the nbench results as the others shouldn't be affected. Lucas
In short, CHILL is a language that you DONT want to use. It's there for two reasons. One is as a simple example front end, and the other is that some poor sods actually use CHILL, and paid Cygnus to maintain the CHILL frontend.
John
John_Chalisque
John_Chalisque
Perhaps Linux does hold back the development a bit, but that's also a good thing. Having everyone add in their own favorite performance tweak, or little fix, will eventually bloat the codebase. If Linux makes a serious mistake, all the other big names will corner him and let him know, but if his only mistake is being a little timid with the stability of the OS...
Besides, he's not going to veto something if it proves to work consistently in test releases. At worse it'll just take a year or so for something to be proven to the point where it gets folded in.
You don't say what platform/language you've tried gcc on but the linker can have a big effect.
On Solaris, my egcs c++ builds are vastly smaller and quicker if I use the GNU linker. If throws away unused virtual function calls etc. If GNU ld is available on your platform I recommend you give it a go. Of course it is already present on Linux.
Alex.
-- Thorin sits down and starts singing about gold.
I'm doing 2nd year computer science and from what I've seen of Ada (which is a lot) it makes bloated binaries, runs relatively slow and tries to cut off all entire low level operations from you.
Granted it's a lot more robust but the costs are too high.
Maybe for some certain apps it would be okay but as far as Kernel is concerned you need something with real speed and portable such as C/C++.
It's turtles all the way down.
Concepts like polymorphism and inheritence are just a little too complex for some C programmers mind to comprehend I guess... As far as clairity, look at GTK's "hello world" vs Qt's. That same ease of coding extends all the way to large and complex applications.
Many (most?) large GUI applications on most platforms are written in C++. Why? It's easier to maintain and troubleshoot the code when everything is a class object, and it's faster than Java. Hardly useless trash.
..such as?
Why don't you compare KSiag vs GSiag, KFM's code vs GMC (and KFM does *much more), KWord vs AbiWord, etc... Like I said, this ease of use extends all the way to large applications.
Many in the hacker/free-software/open-source communities disparage Ada because:
I can understand why a hack programmer wouldn't like Ada (which is what we now call the modern OO language formerly known as Ada95), but most software engineers and disciplined programmers absolutely love it. Loving it, and being able to use it in a project because of political reasons, are often two different things. But on a purely technical basis, Ada rules for complex programs.
On the chance that anyone here might like to learn more, maybe try GNU Ada on their Linux box, see the Home of the Brave Ada Programmers, the starting point for All Things Ada on the web.
And I have to agree with the first poster--an Ada kernel would kick some serious butt. But I'm not convinced that it will never happen. That's what they said about the rise of Linux, and the decline and fall of Microsoft.
KAI C++ makes grand performance claims, and Comeau is another compiler built on the same ECG backend (but much cheaper). I'm mainly interested in the Linux platform for now.
Notes:
The main webpage & what's new on www.gnu.org should be updated too.
> There have been some heavy debates about this on the kernel mailing list and apparently the :-/
> communication between the egcs team and Linus was not very successful
I don't understand that...
What do you expect?
Should the egcs team hack the compiler to work around "missbehaviours" in the linux sources?!?
Linux that has the problem, *not* egcs. Nearly all other pieces of software (incl. other kernels) compile and work just fine with egcs.
Is there _real_ optimization for K6/K7 line?
If still not then it looks very strange to say the least, doesn't it, as K6 is pretty different internally to Intel line.
I bet you have no idea how to use STL.
I know, it can be hard to start for many slow-minded people, but if you persevere and actually learn how it works (including some internal details about its built in memory management) you will understand that it is the best set of containers to use among almost all languages (taking into account both performance, flexibility and easy of use)..
<^>_<(ô ô)>_<^>
Flexibility and portability are two major criterion that you've overlooked. GCC runs on many OSes and with several languages and CPUs.
It's also free. Fast enough. Open.
Just write great software.
"But the webpage isn't updated!" Sounds more of a PHB type comment to me.
How many software people have the ability to write compilers PLUS the drive and free time to do it FREE (as in speech, not beer)? Not many is my guess.
+ Ok, what exactly does that do to the
:-) Yeah, the lack of preprocessed headers can really hurt once they stop changing, but like I said, I (and others) have been surprised at the difference some extra coding makes. Things like redundant include guards really do honestly work on a large project, and testing-in-isolation helps you to run that
:-), but I have to wonder whether distributing a compiler would be worth the overhead. Distributing the entire build, though, where each machine works on a different source file, is very cool, and is just the next logical step in "seperate compilation." Dunno about splitting the individual compilations of files... I wonder if/how Plan 9 does this.
+ compile/test/debug cycle. [...] that's where
+ the ~8min's+ per compile becomes penal.
Do you want the 8 minutes, or the 130 MB?
I was defending the binary size, not the compile times.
debug cycle much quicker, with tiny little testcases.
It also helps to set TMPDIR to a ramdisk.
+ Has anybody thought about a gcc based build
+ environment that can be distributed
I'm not an expert (yet, dammit
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I agree completely.
I've always had a certain amount of ambivalence toward C++. On one hard, it addresses some of the short comings of C; but on the other hand, it has gotten so complex that it rivals Ada in this respect. Probably it's best feature is that it lets one pick and chose the features and paradigm that one wants to use, unlike some languages (which I will not name here, lest I be flamed to a crisp by some language x zealot) which forces one into a certain paradigm.
But I really like generic programming in general, and STL in particular. It's unfortuanate that so few people have experimented with this type of programming.
TedC
True, he seems to be a bit harsh at times, maybe he is. At the same time egcs started as an experimental compiler and up to 1.1.2 there are known optimiser bugs. I think it is quite fair to stay behind here and to say "use this compiler until further notice" to generate the kernel. Since the just the C part is required it does not eat up much disk space either and the kernel is "somewhat" special, fair enough.
Hmm... well, if I was already off-topic enough to mention the interjection thing, I suppose it can't hurt to be off-topic enough to explain it... =)
I haven't ever used that feature myself, and it is certainly good and probably advisable to write programs that don't use it. I think it's one of those things that you want to avoid if you can, but that can really be a lifesaver every once in a while. A situation I can imagine- say somebody wrote a Car class, and subclassed it to Toyota, Honda, Ford, Chevy, et cetera, and then models for each company, from which you are deriving your instances. Now you realize that you have a need to override a method in the Car class for cars built after 1985- so you'd really like your class hierarchy to have Car on top, with all of the companies models as subclasses of Car, and then NewCar as another class, also with all of the companies underneath. There are two problems, though- first, you're duplicating code for a potentially huge hierarchy, which is never good. Second, you may not have access to the source of the classes you're using, or permission to change them, in which case you're SOL with Java or C++. You could make a NewCar subclass of every model, but then you're duplicating your method a huge number of times, and it's a big pain too. The best solution is just to be able to take an object and figure out dynamically whether it's a Car or a NewCar- at some point after all the fields are set, just say "if you were built after 1985, interject NewCar in between Car and your company."
I should again mention that I'm not a hard-core object-oriented Schemer, so I don't really know if that's the point of it or not, but it does seem that it would be useful occasionally.
(Incidentally, I think JavaScript allows for the same sort of thing. Just kinda funny. I'd hate to think that JavaScript might be the choice of a new generation...)
-jacob
I know this won't go over real big on a forum dominated by Linux users, but VC++ generates some really fast code. It's not just simple trimming CPU cycle stuff either; they (MS programmers) seem to be doing a pretty good job of recognizing patterns in code and replacing it with faster algorithms when it's "safe".
TedC
"There ain't no such thing as the fastest code"
Michael Abrash
Well, you succeeded, despite your effort to the contray. "Leave it alone" is not a very helpful answer to his question. What is this, open source, but proprietary information?
I would have answered his question myself, but I don't know the answer either. Hopefully there is someone out there that can give a pointer in the right direction.
Try Magic Exec and parallel make for MOSIX from: http://www.mosix.cs.huji.ac.il/txt_contrib.html http://www.cs.huji.ac.il/mosix/
Am I the only one who thinks gatekeeper.dec.com is slow on mirroring prep.ai.mit.edu theese days? /me is about to change fave GNU mirror :(
It's very cool and I know a lot of OSS projects are grateful for the wonderful contribution people make towards it.
Great job!!
Pardon my idiocy, but I have a few questions since I am so thoroughly confused.
Is EGCS going to replace GCC? Is it going to be/already is GCC? Is it going to live side by side with GCC?
My confusion stems from the fact that I seem to remember something about a name change for EGCS being posted on Slashdot not too long ago, and being fairly confused then. Now I can't remember what the name of my favorite compiler will be, and what neat new tricks it will have nestled inside.
You can install the new version without wiping the old, so at least you can use -V if all else fails.
how? uh..
this may sound dumb, but what is the configure script for glibc?
..buy GCC from Cygnus? I have heard that the commertial version that they sell (GNUPro and
CodeFusion) has new IA32 backend already installed. According to the ad for the CodeFusion on the Cygnus site, it has 80% speed increase over "net egcs" for Pentium II for specific benchmarks (its on par with Intel's Proton(?) compiler on that, and 30% faster than VC6.0)
Problem is CodeFusion is not shipping yet..Should be a matter of days(?). Don't know if the latest GNUPRo has the same optimizations.
<^>_<(ô ô)>_<^>
Yes, glibc2 should continue to work fine after you upgrade gcc.
I ate something that disagreed with me. Maybe I should have cooked him first.
The next gcc release will be egcs and the egcs name will be dropped.
Here
Citation..
(1) Code Fusion produces code that is 85 percent faster than the current Net GNU release, 20 percent faster than the Microsoft Visual C++ 6.0, and equivalent to Intel's Proton compiler. These results are based on the Integer Index performance in the byte benchmark.
<^>_<(ô ô)>_<^>
Right, bash is the interpreter!
In C++, of course ;-)
Although Python is nice and integrates well with KDE.
egcs replace the gcc/g++ collection,
But now egcs is being renamed to GCC.
So gcc is the c compiler,
and GCC is the compiler collection.
Dumb, if you ask me.
They should have called it gcs to avoid this confusion.
Up this late? Friday night? Man, it's noon on :)
a Saturday at least here in Funland
So, has anyone had anyone had any luck getting this to compile with
last1120c or prestruct-c?
> It's biggest drawback is that it can obfuscate
> inefficiencies in code. What looks like a
> simple assign (or memcpy) can end up
> serializing and parsing at a high cost.
This is true, but you can just take a look at the assembler listing. The tough part (for me) is figuring out why it thunk to do what it did in the first place.
> The problem starts when sombody else has to
> maintain the code. They end up loosing the
> advantages of OO code because they either have
> inefficient code, or have to study the objects
> and their relationships just as deeply as they
> would in C.
I disagree. Its always easier to understand *well-written* object oriented code (in C or C++) than structured code (in C or C++). And the warts that result from C's lack of OO constructs obfusicate OO code written in C. Writing efficient code has little or nothing to do with the language. It has much to do with the design and the developer.
> Personally, I find that by the time I dig
> through C++ code (for the fabled ease of code
> reuse) to check for those problems, it would
> have been just as easy to cut/paste C code.
Reuse comes from documenting the reusable code (in C or C++). So, if you have to dig through it, it probably wasn't designed to be reused. Cutting and pasting almost always gives more, buggy (due to cut/paste errors) code that needs to be maintained.
> C++ does have a few nice features. Most of
> those seem to be in the process of back-porting
> into the C standard.
The only reason to use C++ is its OO features. I hope the structured enhancements do go back into C, but don't know of any case personally when someone used C++ to get these.
> In cases where OO is the right approach, but I
> want to make the cost of various operations
> quite explicit. The Linux kernal is written
> that way.
Actually, if you read the kernel mailing list FAQ, they once did a C++ port, and it was significantly slower due to the quality of the compiler. The other reason they site for use of C is that that's what kernel programmers know, which is currently true.
Changes aren't permanent, but change is.
What is the performance of binaries compiled with gcc 2.95 compared to that of binaries compiled by pgcc and will the source changes that pgcc has made to egcs be envtually returned to the main source tree?
Cheers
Lucas
> C++ is overcomplicated, mostly because it is
> too low level and high level at the same time.
This is the same comment that Pascal programmers made about C back in the early 80's. The reason C is so successful (and Pascal is not) is that it can do almost everything that assembly language can do. So, when a generation of people trained in Pascal, FORTRAN and PL/I started doing systems programming, they dumped assembly in favour of C.
I'm betting the same will happen with C++. A new generation of programmers trained in Java will want to write systems code in an object oriented language, but will be prevented from using Java due to its non-deterministic nature. The obvious choice will be C++.
In other words, your perceived weakness is actually a strength.
Changes aren't permanent, but change is.
ObFanboyComment: GO GCC!!! :-D
Would this be the one with Intel's new IA32 backend? It'll be great to finally see gcc kick VC++ butt on x86 binary quality. I'm getting this strange urge to recompile everything -O9 -mpentium }:-)
iSKUNK!
weakness or not, I don't like C++,
& I don't like OOP, but I don't dislike
C++ because it's an OO language(OO capabile if you
will). While I do dislike OOL's because they lead
too OO code, which in my view is akin to lazzy programing for lazzy programers, I dislike C++
simply because somehow they managed to take a
very elagent language like C and made it into
the world's biggest cludge. The source code's cludgy, the binary code that get spitout is cludgier still with all the mnagleing going on.
I suffer from a programing defect, I simply can't
trust "Objects" unless I know(and by know, I mean
"I"! told it to do it, not some bloody parent object of somesuch) whats going on at all times.
C is simple & explicet. No intersecting mapings
of raw procedural code into sudo object's for
programer's who have the capability of beliveing
or at least useing the "lie" that an OOL lets
a programmer belive(use?)
ahh well, rant rant rant.
Does anyone know where I can get RedHat 6.0 RPM's for this? Would be greatly appreciated!
It's far easier to build reliable systems in C++ than in C. It's merely your ignorance of the language and its use that creates problems--I used to think the same way, but experience taught me otherwise.
First off, C++ is not an OO language... it supports lots of non-OO styles (such as generic programming via templates, with the STL being a good example of non-OO code that's virtually impossible to do well in C).
Second, the main reason some people object to C++ is that they simply have no programming experience in any program large than a simple demo or textbook examples.
I'm not sure... performance is mostly better, but the new Cygnus IA-32 backend isn't in this version... It'll increase performance about 30% over 2.95
PGCC and GCC (ex-egcs) pretty much share code heavily, but it's unlikely that the compilers will merge, they are made for different reasons..
And the developers of each have not really had an exactly romantic co-existance.
- Faktorii
When the alias issue came up, Linus told the compiler people to use a set of rules to turn aliasing off, instead of immediately correcting the bug in Linux (it is a bug, because it violates ANSI C aliasing rules, and he was shown at least two ways to fix it.)
That's not good engineering, to write buggy code and expect other people to fix the tools to work around your buggy code.
I have found STL to be one of the most useful features of C++. Period. It allows the programmer to work more closely to the problem desgin, and get very efficient code to boot.
For decades, thousands of programmers have re-invented the wheel by providing their own implementations of containers and container algorithms. It's time to grow up, and and STL is an excellent start.
If you need help using STL I suggest you look to the Stroustrup as it has excellent explanation and examples. Additionally, the folks c.l.c++.mod are happy to answer questions.
That's not good engineering, to write buggy code and expect other people to fix the tools to work around your buggy code.
Especially given that there's a flag to turn off the code that exposes the bug already. Linus was still pissed because he wanted the performance benefits of strict aliasing without having to clean up the kernel code to not violate the aliasing rules.
The problem I have with egcs/gcc is the the glacial compile times!! I am running on a dual 450 PIII and it takes 5 times as long to compile (no optmisations) my app as it does on PPC/Codewarior on a single CPU PCC/300. This is probably because of the lack of precompiled headers. Much of the source includes the headers to libs and system stuff.
However, ***BY FAR*** the most absurd thing about the GCC tool chain for x86 is DWARF!! My 4 Meg executable swells to a mindboggling 130MB of god-knows-what nonsense when the -g flag is on.
Linking this beast takes ~8 minutes and nearly brings my 256MB RAM machine to its knees.
The thought of porting my company's code to Linux is very appealing, however I can't even imagine the pain of doing so with the current tools. My only option seems to be spend some undetermined amount of time fixing the tool chain --- if its even possible -- something tells be if it was a reasonable task to fix the Broken-As-Designed aspects of the gcc/dwarf and the debugger (no doubt all three would need to be revd.) then someone would have done so long before now...
I am not trying the flame-bait the GCC/Linux is the holy grail crowd here, but the current situation sucks for those of us with beefy apps.
--BQ
"Bruce Q Hammond" bruceq@gobe.n.o.s.p.a.m.com
Ok, this thing supports chill...
I apologize for asking such a stupid question here, but... could someone please tell me what kind of language chill is, and where I could find more information about it? Thanks in advance!
To compile Linux 2.2x with gcc 2.95, you need to include the flag -fno-strict-aliasing
This flag is needed if you have code that does things like try to read an array of longs as an array of shorts, without using unions.
I'm having problems compiling it for HP-UX 10.20. Any ideas?
;-)
(I haven't actually finished downloading it yet, but I just know I'm gonna have problems with this crappy OS
Since nobody here have really said it I want
to say thank you to all developers that spend
their time making gcc better.
I use gcc/g++ almost every day and I am very pleased with it.
As a blatant plug I'd also like to say that the GNU Webmasters need more help. Do write me if you want to help out.
A big thank you to all the developers of the GCC compilers :-)
*we're not worthy, we're not worthy, we're not worthy....*
Will pgcc be merged with gcc, or what is that status of that?
building for mingw32 as i write this
Be kind. There are too many mean people out there already.
I was just reading the linux kernel mailing list (which i *just* resubscribed to) and apparently, the kernel won't compile correctly with gcc 2.95. Here's an excerpt:
The linux kernel violates certain aliasing
rules specified in the ANSI/ISO
standard. Starting with GCC 2.95, the gcc
optimizer by default relies on these
rules to produce more efficient code and thus
will produce malfunctioning
kernels. To work around this
problem, the flag -fno-strict-aliasing must be
added to the CFLAGS variable in
the main kernel Makefile.
Disclaimer: I haven't downloaded the new compiler and so I haven't tried it yet, but keep this in mind when you upgrade gcc.
Will it break my system? What are the requirements? Will the kernels compile with it? how about other large projects such as X, Apache, Gnome, KDE.
The compiler is one of the core programs if you don't use binaries so the over-all stability of your Linux box greatly depends on a good combination of compiler, libraries, includes etc etc.
Is there a HOW-TO available on this? (not just saying: "old goes with old and new with new" or providing upgrade instructions for a specific compiler but more a general document describing how some parts of the system work together and how to make optimal use of that)
Are there any commercial compilers that are as retargettable as gcc?
Cygwin's original claim to fame was the embedded software realm (you pretty much HAVE to have a retargetable compiler)....
I would imagine that any programming language would be difficult for this person, given his lamentable inability to spell even the most simple English words, let alone arrange them into intelligible sentences.
Mnagleing, indeed. Lazy people don't check their output. Heaven knows what "lazzy" people do.
What concerns X, I just compiled XFree 3.3.4 with gcc 2.95. It compiled fine and it runs a hellovalot faster. This is on an Pentium II-400, with Linux 2.2.10 (also compiled with gcc 2.95 and -fno-strict-aliasing). EGCS Team: Well Done! This is a *great* improvement ;). -- sdt
Hmmm. That might be worth checking out. I wish they had an evaluation version; as Mindcraft recently reminded us, benchmarks can be used to prove anything. Also, I would like to know whether GNUPro contains the same compiler technology as CodeFusion, since I couldn't care less about their IDE.
I assume that purchasers of CodeFusion and GNUPro aren't free to redistribute source. Given that part of their product is a derivative of gcc/egcs, how do they manage that without violating GPL?
Hmmm.... You'd think slash would be integrated with a spel checker by now.
-russ
Don't piss off The Angry Economist
Sigh. Too bad more aren't using a software engineering OO language since there is now such a rich choice available under the GNU license: Eiffel, Ada95, Sather (among the safest). Even Modula3, Smalltalk, and Java are worthy of consideration. Here's some URLs,
GNU Eiffel
GNU Ada95
GNU Sather