GCC 4.0 Preview 684
Reducer2001 writes "News.com is running a story previewing GCC 4.0. A quote from the article says, '(included will be) technology to compile programs written in Fortran 95, an updated version of a decades-old programming language still popular for scientific and technical tasks, Henderson said. And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'"
C++ compiler (Score:5, Insightful)
Mudflap (Score:5, Insightful)
I really love this feature, it will probably cut down on a great deal of problems. My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.
More detailed information on the mudflap system can be found here [gnu.org].
and how many times... (Score:5, Insightful)
The biggest challenge with Binary compatability across Linux distros is the GCC release (followed by the glibc releases, who live in the same ivory tower). I realize that things have to change, but I wish that they would not break compat between versions quite so often...
I'd really like to be able to take a binary between versions, and it just work.
This is one area where Sun rocks. Any binary from any solaris2 build will just work on any later version. With some libraries, you can go back to the SunOS days (4.1.4, 4.1.3UL, etc). That's 15 years or so.
sane error messages when using templates (Score:4, Insightful)
Favorite quote from the article (Score:5, Insightful)
Why not run it all the time? (Score:2, Insightful)
Besides, it might just be automating the addition of the same code that we would need to put in to fix buffer overrun vulnerabilities.
This is one case where I think it's worth "wasting" a small amount of performance (except perhaps in routines that need to be highly optimized) to give added security. Sure beats ray-traced-on-the-fly desktop widgets, or something, which you KNOW we're goingto see advertized in another decade.
Re:Mudflap (Score:2, Insightful)
It will create a false sense of security.
During developing/testing problems are found and hopefully fixed. It is the problems that are NOT found that create vulnerabilities.
Re:Mudflap (Score:3, Insightful)
For some users and some classes of applications, it will be OK. Sometimes security is more important than performance, and you can't imagine the weird stuff your code sees when it's in the customers' hands.
More incompatibilities on the way? (Score:3, Insightful)
Re:GUI (Score:4, Insightful)
Re:More incompatibilities on the way? (Score:5, Insightful)
C++/Java Compiler Comparisons (Score:2, Insightful)
Re:I just want C++ programs to COMPILE faster (Score:2, Insightful)
I'd rather use straight C at this point than C++ with the STL. Java is ever more elegant, perhaps one reason it eclipses C++ in the general business environment. (OK, so there's the generally accepted benefits of built in memory management to prevent neophytes from stubbing their toes and bringing down the house....) But with the JDK improving performance with every release, and Java gaining many of the lacking items in the the 1.5 release (ok, so some are compile time only) it's easy to see why Java continues to be a favorite of developers.
Re:More incompatibilities on the way? (Score:4, Insightful)
Re:Screenshots! (Score:3, Insightful)
Funny, but it does highlight something that annoys me. Make/gcc output.
For the last few weeks I've been compiling a set of apps that's about 5x bigger than just the Linux kernel (it includes the kernel too). Watching the make/gcc output scroll by I've decided one thing: I *hate* it.
GCC itself is fine. It only does something when there are errors. Make, on the other hand, spits out every command it runs and all kinds of things that I really don't care about.
Without the bloat of a full-fledged IDE, is there such a thing as a make-wrapper GUI? Here's what I'd want:
I'm sure I could come up with some more enhancements, but that would really make me happy. I know the 2.6 kernel has gone a few steps in this direction but it is far from enough.
But if faster has been decremented... (Score:4, Insightful)
Re:How about support for older levels? (Score:3, Insightful)
A start would be sticking to ISO C. If you can possibly avoid it, steer clear of writing code targetted at a specific compiler.
Re:Autovectorization (Score:4, Insightful)
Re:Mudflap and buffer overflows (Score:1, Insightful)
You realize that, once MudFlap detects a possible buffer overrun error in the code, you can fix it, right? And then, it's not there any more? That's what MudFlap does. It CHECKS for buffer overruns. It's up to your lazy ass to fix it. Leaving it in a production version is worthless... unless your end users want to be informed that the programmer was too lazy to fix buffer overruns that he knew about. It's a 5% slowdown, or a 0% slowdown for fixing your damn code and not using mudflap in a production version. NOW which would you choose?
Re:I just want C++ programs to COMPILE faster (Score:3, Insightful)
Funny, I thought real coders used the right tool for the job, or is that real smart coders?
Re:Mudflap (Score:5, Insightful)
I have been using C since 1980. I have seen dozens of attempts to fix C semantics since then. I published some papers on it myself. It can't be done efficiently. The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.
Where does the factor of 3-5 come from? From the Mudflap paper on the Mudflap web site--it has benchmarks.
Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.
And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too. So, C is not only bad for efficient safe code, it is bad for efficient code of any form.
I am getting sick when C-hating posts like this one get modded up. Seems to be happening all the time lately.
I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century. It's even more annoying that you try to portray your ignorance and inexperience as some kind of principled stance. C was good for what it was 30 years ago: an on-board compiler for writing small, low-level programs on machines with very limited memory. C made a decent PDP-11 compiler for V7 UNIX, and it was usable on CP/M and MS-DOS. I have fond memories of it in those environments.
I'm starting to meta-mod again.
You do that. If you join forces with enough other idiots, you will probably be able to condemn us to another quarter century of bad pointers, buffer overruns, and bloat.
Re:How about support for older levels? (Score:2, Insightful)
Re:Yes, it's true (Score:1, Insightful)
how LLVM would harm gcc (Score:5, Insightful)
LLVM can be used as a GPL bypass. If this were to
become a problem, people would not feel as good
about contributing to gcc.
Well, that's how RMS thinks anyway. Never mind that
adding LLVM would enable some really neat stuff.
Re:GUI (Score:2, Insightful)
MyIDE = xterms + vim + grep + make + svn + man + the browser + diff + io redirection +....
It's not as polished as an IDE, not as cool. But you get to organize it any way your want.
And besides, considering most of my time is spent manipulating text, any IDE that doesn't have vim integrated in it is useless, at least to me.
(NB: if you like, you can subst emacs for vim in the above)
my guess (Score:3, Insightful)
Re:C++ compiler (Score:3, Insightful)
[snip]
But it's the same parser as g++ 3.4. It is faster (and fixes bugs) compared to g++ 3.3, but calling it "tremendously faster" seems a bit of stretch.
Re:I just want C++ programs to COMPILE faster (Score:2, Insightful)
Re:Ahem. (Score:3, Insightful)
Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)
This is exactly the ivory tower thinking that the poster is complaining about. You are overestimating the maintenance cost und underestimating the pain for your users. This is typical for open source: think that what is good for the developer justifies major compatibility issues for everybody else.
Re:distcc and ccache is better than compile server (Score:3, Insightful)
Saying that distcc is "less error prone" is a meaningless statement since you're comparing distcc against an unfinished project. The compile server can work "even when preprocessor tricks are used" - give us credit for having thought about the issues, and having come up with solutions, albeit partially implemented and not necessarily optimal.
Your compile server makes a lot of assumptions that many popular projects break.
So what? As long as many projects can benefit from it. If some projects benefit, that would encourage other projects to clean up their header files, which would be a good thing in itself. (A side benefit of the compile server is that it encourages clean design.)
I agree discc is far simpler, and it will be challenging to engineer a compile server that can detect and recover from header files that aren't "clean", without the checks taking so much time we lose most of the benefit. It's essentially research, and there is no guarantee that it would justify the investment needed. But it does have good potential.
Note there are some limitations for distcc. First, of course it assumes you have multiple idle machines you can spread your compiles to. That may not be the case in a home environment or when travelling. Second, shipping pre-processed source code all over the place is quite expensive. Distcc doesn't save you time in preprocessing, optimizing, or code generation. All it helps with is parsing and semantic analysis, so the best it can give you is a modest constant-time improvement. By this I mean that if you have M files that include N header files each, the compile-time with distcc is O(M*N), but with the compile server it could potentially be O(M+N).
Re:Mudflap (Score:3, Insightful)
Pretty much any of those newer languages (I assume you mean Python, Ruby, Lua, et cetera) provide a C API for adding module interfaces (useful for doing fast calculations, access to C libraries, low-level operating system or device communications, et cetera). You shouldn't be afraid of mixing languages. It's the only way to really get the best of both worlds.
Re:Mudflap (Score:3, Insightful)
You don't need to Google, you just need to follow the links at the top of the story!
How does the C sematnics make it hard for the complier to iperform checks on buffers?
Because, for practical purposes, C pointers have to be naked memory addresses that can point into the middle of an arbitrary sized chunk of memory. That means that, unlike implementations of other languages, a C implementation cannot simply get information about bounds or types by looking up data at a fixed offset relative to the pointer.
There are plenty ways to prevent buffer over-runs these days.
Yes, like using a decent language with a minimum of built-in error checking and a sensible type system. We have had them, oh, for about half a century. And nowadays, you can even choose among a bunch of mainstream languages like that: Java, C#, VisualBasic, OCAML, and Python, to name just a few.
Do you have any links at all to contribute?
I have no idea what your background is; you might high school kid that writes viruses in C in his spare time and thinks that C is the k00lest thing since Britney Spears. But if you seriously want to learn about this sort of thing, look at the Cyclone papers (you can find them on Google) and check their references, as well as references to them in the literature. You'll reach a large collection of papers on trying to make C safe. Pick and choose according to your interests.
Re:Ahem. (Score:1, Insightful)
Re:Ahem. (Score:3, Insightful)
You are overestimating the maintenance cost
How come you can judge the maintenance cost better than a GCC developer?
Re:C++ compiler (Score:3, Insightful)
Re:Ahem. (Score:3, Insightful)
Re:C++ compiler (Score:1, Insightful)
You got that the wrong way round. (Score:1, Insightful)
Re:Mudflap (Score:3, Insightful)
The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.
Yes, it is, but C has other strengths that make it worth.
Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.
But all those languages face a performance hit compared with C even with safety off.
And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too.
One need that optimixation when have no control of his pointers. But a well written program on C can be as fast without the compiler optimization. Also, a good design can avoid the bloat without compromissing security and also generate optimizations for the places where safety can be off.
I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century.
I am design a very speed sensitive library. Which "modern" language do you recomend me? On what language can I keep my arrays at the stack, like I'm doing on C for better speed? And on what language I can create an entire (less powerfull but faster) memory management library to avoid a bottleneck like I did with C (C++ actualy)? Think twice before you call most of the people out there idiots. Obvoulsy there are programs that worth the pay-off of using an easier language, but before you ban C, try to realize that there are applications that doens't worth it. And since some of them are the compilers of your "modern" languages, don't see how supporting C delay their developpment.
And, before you try to arguee, I belive on the better tool for the job. That is why I currently have 4 projects, one in C++, one in Java, one in Perl (learning) and one in Bash script. I am not a blind C overload.
Re:Ahem. (Score:3, Insightful)