GCC 4.0 Preview

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

Comments

Re:OpenMP?

[Anonymous Coward]

Sun has a nice summary of OpenMP here

It's pretty cool. You write a loop like this:

#pragma omp parallel for private(sum) reduction(+: sum)
for(ii = 0; ii < n; ii++){
sum = sum + some_complex_long_fuction(a[ii]);
}

and the complier will handle the creation and syncronization of all the threads for you. Here's a OpenMP for GCC project on the FSF site. Looks like it's still in the "planning" state, though, so I'm guessing it's not in GCC 4.X.

Autovectorization

[DianeOfTheMoon]

One optimization that likely will be introduced in GCC 4.1 is called autovectorization, said Richard Henderson, a Red Hat employee and GCC core programmer. That feature economizes processor operations by finding areas in software in which a single instruction can be applied to multiple data elements--something handy for everything from video games to supercomputing.

Is it just me, or is this the first "we will make it easy to program the Cell" step that Sony and IBM were promising?

Re:boost, please ?

[devphil]

What does GCC have to do with this?

If you want something added to the standard, talk to the C++ standard committee. (Either the Library or the Evolution groups, in this case.) You'll find you're about the 10,000th person to ask for this. You'll find there's an extensive FAQ on this exact subject. You'll find that the committee is very keen on adapting large parts of Boost, as experience in the real world smooths the rough edges of Boost.

If you look a bit more, you'll find that some extensions have already been adopted (called "TR1") and are being shipped with GCC 4.0.

You'll also find that GCC does not get to determine what's in the standard. And -- speaking as one of the libstdc++ maintainers, although I'm largely too busy to do much myself these days -- GCC will not ship Boost. Or glibc. Or libAPR. Or OpenSSL. Or any of the other million very useful open source libraries out there, because that's not our job.

Re:OpenMP?

[multipart]

We're working on the necessary infrastructure to associate the pragmas with the syntactic constructs they apply to. Actually parsing the OpenMP directives was already implemented - twice - but GCC does not support pragmas with a lexical context yet. This is needed for a bunch of C extensions, so we're working on that. This is probably GCC 4.1 material. After that, actually generating concurrent code from OpenMP pragmas is next.

Ahem.

[devphil]

I realize that things have to change, but I wish that they would not break compat between versions quite so often...

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

We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.

I'd really like to be able to take a binary between versions, and it just work.

Wanna know when this is gonna happen? Sooner, if you help.

Re:C++ compiler

[Anonymous Coward]

Apparently. Found via google:

http://people.redhat.com/bkoz/benchmarks/

Doesn't look public though.

Re:I just want C++ programs to COMPILE faster

[mzieg]

I use "using namespace std;" in the common include files of all of my home-built programs.

It's generally regarded as a Bad Idea to place using directives in header files.

They propogate down into every .cpp that includes your library's headers, whether or not the calling programmer wanted to import the entire std namespace.

Some programmers may have their own classes called map, or string, or list, or a dozen other things, and a single using statement buried in a nested .h can cause unanticipated namespace collisions.

In general, it's safest and most polite to refer to classes canonically in header files (std::string, etc), and keep the using statements in your implementation files.

Sources: "Accelerated C++" (Koenig, Moo); comp.lang.c++ (sample)