Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GCC 4.0 Preview

timothy posted more than 9 years ago | from the dual-overhead-cams dept.

GNU is Not Unix 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.'"

Sorry! There are no comments related to the filter you selected.

GNAA APPROVES OF GNU (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11937954)

(GAY NIGGER UNDERWEAR)

OpenMP? (3, Interesting)

Anonymous Coward | more than 9 years ago | (#11937955)

What I'd like to see is features like OpenMP for thread-level parallalism.

Re:OpenMP? (5, Informative)

Anonymous Coward | more than 9 years ago | (#11938000)

Sun has a nice summary of OpenMP here [sun.com]

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 [nongnu.org] 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.

Re:OpenMP? (0)

Anonymous Coward | more than 9 years ago | (#11938090)

This looks oddly familiar.

Re:OpenMP? (5, Informative)

multipart (732754) | more than 9 years ago | (#11938157)

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.

I just want C++ programs to COMPILE faster (4, Interesting)

drinkypoo (153816) | more than 9 years ago | (#11937962)

Is it just me, or is compiling C++ code an order of magnitude slower than compiling C code? (exaggeration) I'm sure there's a very good reason why this is so, but it still doesn't make me happy.

Re:I just want C++ programs to COMPILE faster (2, Informative)

keesh (202812) | more than 9 years ago | (#11937988)

A lot of it is down to templates. As soon as you use them or STL you're upping the compile by an order of magnitude and gobbling up a hundred megabytes of RAM... With great power comes a cost.

Re:I just want C++ programs to COMPILE faster (2, Interesting)

drinkypoo (153816) | more than 9 years ago | (#11938025)

I don't mind pissing away RAM, I'm willing to spend 200MB if they can just do it faster, maybe through aggressive caching?

Re:I just want C++ programs to COMPILE faster (1)

joto (134244) | more than 9 years ago | (#11938192)

I don't mind pissing away RAM, I'm willing to spend 200MB if they can just do it faster, maybe through aggressive caching?

If you eat a lot of RAM, it will take some time to fill that RAM with interesting stuff, process it, and get even more interesting stuff out of it. And even now, gcc will happily eat 200MB for "modern C++" templatized source code.

Aggressive caching? How about ccache [samba.org] ?

Re:I just want C++ programs to COMPILE faster (1)

drinkypoo (153816) | more than 9 years ago | (#11938269)

ccache only helps on subsequent compiles of the same code, which is not very exciting to me since I don't generally compile the same version of something repeatedly.

Re:I just want C++ programs to COMPILE faster (1)

lederhosen (612610) | more than 9 years ago | (#11938005)

No, it really is _much_ slower to compile c++

Re:I just want C++ programs to COMPILE faster (2, Insightful)

Gr8Apes (679165) | more than 9 years ago | (#11938240)

Having just viewed C++ for the first time in 5 years, I must say, yuck! Namespaces in the STL are what drove me from C++ in the first place. I'm glad they got the STL to work, but namespaces are still ungodly ugly, and their pervasiveness within C++ make what used to look like an elegant language an ungainly loaded behemoth Pascal offspring, and compiling it pretty much brought down a decent SGI machine of the time.

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:I just want C++ programs to COMPILE faster (5, Funny)

Profane MuthaFucka (574406) | more than 9 years ago | (#11938270)

It does take longer to compile C++. The solution to this is to keep Slashdot open in a browser. Back in the days before Slashdot, when compiling took even longer, programmers actually used to go ape-shit watching the compiler. We live in wonderful times.

watch out (5, Funny)

fanblade (863089) | more than 9 years ago | (#11937970)

"...software written in the C++ programming language should run faster--..."

Is this the programmer's way of saying it will run at some speed less than faster?

Re:watch out (5, Funny)

r00t (33219) | more than 9 years ago | (#11938044)

No, that's a postfix "--" operator. This software will run faster. Other software, trying to be faster, will be at a disadvantage because "faster" has been decremented. This is really just a sneaky way to make other languages look bad.

C++ compiler (4, Insightful)

pchan- (118053) | more than 9 years ago | (#11937971)

But will it compile C++ any faster? The difference between compile times of C and C++ files is staggering. Compiling Qt/KDE takes forever with gcc 3.x.

I'm so sorry, ... (4, Informative)

kompiluj (677438) | more than 9 years ago | (#11938037)

but the reason it takes forever to compile KDE lies in fact that it uses extensively the templates. While templates (a.k.a. generics) are a very useful language feature, they increase compile times. Including support for export template feature could help but only when anybody would use it in their code.
You can make an experiment and try compiling KDE with Intel C++ or Comeau C++ compilers, and see that not much can be gained comparing to GCC.

Re:C++ compiler (0)

Anonymous Coward | more than 9 years ago | (#11938064)

GCC 4.0 compiles C++ code 25% faster than 3.4.x which previously held the GCC C++ compiling speed record.

Re:C++ compiler (4, Informative)

bill_mcgonigle (4333) | more than 9 years ago | (#11938201)

But will it compile C++ any faster?

Yes, from here [apple.com] : "
GCC 4.0 features an entirely new C++ parser. The new parser is tremendously faster than the one in GCC 3.3 and will have a noticeable benefit when building C++ based projects.

Re:C++ compiler (4, Interesting)

Surt (22457) | more than 9 years ago | (#11938250)

It claims the c++ front end is as much as 25% faster.

Ahhhhh... Time to start compiling all overagain... (0)

Anonymous Coward | more than 9 years ago | (#11937972)

To think I just got GCC 3.4.3 cross-compiling for my AVR and Coldfire chips, and I get to start all over again.

Progress. I love it!

Re:Ahhhhh... Time to start compiling all overagain (1)

lintux (125434) | more than 9 years ago | (#11938081)

Why would you have to use GCC 4.0 for those platforms? I used GCC-3.x for the AVR platform and it did everything I needed... (Which isn't a lot on those machines, I'd say.)

Re:Ahhhhh... Time to start compiling all overagain (0)

Anonymous Coward | more than 9 years ago | (#11938245)

It's not a "Have to use..." it's a "Well, will GCC 4.x make my programs fit better in 2048 bytes."

Yeah, something that article does not bring up... (3, Interesting)

PaulBu (473180) | more than 9 years ago | (#11938170)

That GCC is the staple in the embedded world. They could've mentioned that most probably it is the compiler used for the proverbias Internet toaster, or maybe even something sexier, like Formula-1 engine-tuning app... ;-) Apparently the article is written to educate the "general public", would be nice to put this little tidbit into their minds..

Paul B.

Shockingly better? (0)

Anonymous Coward | more than 9 years ago | (#11937973)

Have they found some new-fangled magical technique for compilation?

Re:Shockingly better? (3, Informative)

bill_mcgonigle (4333) | more than 9 years ago | (#11938175)

Have they found some new-fangled magical technique for compilation?

Actually, SSA trees probably count, which is new in GCC 4 (invented in the early 90's). Look here [apple.com] , scroll down to "Power Through Builds" for a list of improvements from SSA trees.

Of course, this claim may be due to no longer doing something shockingly inefficient.

Mudflap (5, Insightful)

SteelV (839704) | more than 9 years ago | (#11937990)

"GCC 4.0 also introduces a security feature called Mudflap, which adds extra features to the compiled program that check for a class of vulnerabilities called buffer overruns, Mitchell said. Mudflap slows a program's performance, so it's expected to be used chiefly in test versions, then switched off for finished products." - from the article

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

Why not run it all the time? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11938072)

The protection from buffer overruns is valuable enough that perhaps it is worth including all the time. After all, who knows what vulnerabilities lurk after you "turn off" mudflap?

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 (2, Insightful)

RetroGeek (206522) | more than 9 years ago | (#11938076)

I really love this feature, it will probably cut down on a great deal of problems.

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 (2)

dynamo (6127) | more than 9 years ago | (#11938129)

Uh, doesn't this imply that testing itself creates a false sense of security? Sure, let's not bother testing. Great solution.

Re:Mudflap (1)

0racle (667029) | more than 9 years ago | (#11938084)

So... GCC4 has a propolice look-a-like.

Re:Mudflap (2, Informative)

multipart (732754) | more than 9 years ago | (#11938197)

No, propolice is something entirely different. That's a stack smashing protector. Mudflap is a bounded pointers implementation.

Re:Mudflap (2, Insightful)

bill_mcgonigle (4333) | more than 9 years ago | (#11938096)

My only concern is that some devs will think running it all the time is OK

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.

Re:Mudflap (1)

Trillan (597339) | more than 9 years ago | (#11938100)

I dunno. I think if a programmer has a misunderstanding of security like that I'd rather have a slower, more trustworthy program! But yes, competent programmers would be best.

Re:Mudflap (1)

fitten (521191) | more than 9 years ago | (#11938258)

What about valgrind? (I guess mudflap will work everywhere and valgrind is x86 is the advantage.) I use valgrind all the time, it's a great tool.

Autovectorization (5, Informative)

DianeOfTheMoon (863143) | more than 9 years ago | (#11938002)

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:Autovectorization (1)

fwice (841569) | more than 9 years ago | (#11938054)

I'm guessing that it's going to be similar to the vectorization capabilities of matlab. for example:

% create a vector of numbers from 0->2pi
x=[0:pi/4:2*pi];

% take sin of values
y=sin(x);

which will take all of the sin values of the y, as opposed to the for loop:

for m=1:1:length(x)
y(m)=sin(x(m));
end

the vectors run much faster...

Re:Autovectorization (0)

Anonymous Coward | more than 9 years ago | (#11938068)

For things like the Cell processor, you'd be better off with something like OpenMP [intel.com] that is designed for spreading threads across multiple execution units such as those in the Cell processor. All autovectorization does is help with things more like MMX.

Re:Autovectorization (1)

Duncan3 (10537) | more than 9 years ago | (#11938124)

"autovectorization" has been in the works for about 30 years longer then Cell has been on the roadmap.

In thne shorter term, GPU's have been pushing this line of research hard for a few years as well.

Re:Autovectorization (3, Informative)

s0me1tm (859311) | more than 9 years ago | (#11938266)

Autovectorization is for SIMD [wikipedia.org] , not for SMP [wikipedia.org]

Screenshots! (5, Funny)

Anonymous Coward | more than 9 years ago | (#11938004)

Screenshots, screenshots! I need screenshots people!!!

Re:Screenshots! (4, Funny)

SteelV (839704) | more than 9 years ago | (#11938082)

Screenshot [pc-magazin.de] .

Knock yourself out, bud!

Re:Screenshots! (4, Funny)

Espectr0 (577637) | more than 9 years ago | (#11938125)

Ask and ye shall receive:
http://www.algorithm.com.au/albums/screenshots/lon g_gcc_cmdline.png [algorithm.com.au]

Re:Screenshots! (0)

Anonymous Coward | more than 9 years ago | (#11938254)

Oh man, I think I just messed my pants...

TISSUE!

Re:Screenshots! (1)

Mad Merlin (837387) | more than 9 years ago | (#11938275)

Well, it's not GCC, but here's Vim for Women (TM) [24.150.133.43] . Note that you can't actually edit anything...

Re:Screenshots! (1)

Geoffreyerffoeg (729040) | more than 9 years ago | (#11938276)

% gcc-4.0 -o helloworld helloworld.c

%

boost, please ? (3, Interesting)

savuporo (658486) | more than 9 years ago | (#11938011)

Can we get Boost [boost.org] in standard library please ?

Re:boost, please ? (2, Informative)

yamla (136560) | more than 9 years ago | (#11938042)

I'd love for boost to be in the standard library, but I'm not sure that complaining to the gcc folks is the way to get this done. Surely if we want this in the standard library, it should be included as part of the next version of the ISO C++ standard?

Re:boost, please ? (1, Informative)

Anonymous Coward | more than 9 years ago | (#11938103)

Read the site you just linked:

Ten Boost libraries will be included in the C++ Standards Committee's upcoming C++ Standard Library Technical Report as a step toward becoming part of a future C++ Standard.

So yes. Eventually, anyway.

Re:boost, please ? (5, Informative)

devphil (51341) | more than 9 years ago | (#11938144)


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:boost, please ? (1)

zbyte64 (720193) | more than 9 years ago | (#11938217)

i find boost is really ugly... mainly cuz template programming was never meant to be used that way. Now OpenC++ is a very nice project where u can modify/generate code at runtime using relfection like principles. It is very extensible and the limits are far from seen. http://opencxx.sourceforge.net/

and how many times... (5, Insightful)

Zapman (2662) | more than 9 years ago | (#11938019)

And how many times will they break ABI, API and library compatability in THIS major release? Count stands at 4 for the 3 series, maybe higher.

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.

Re:and how many times... (0)

Anonymous Coward | more than 9 years ago | (#11938126)

Anything that changes parameter passing will make anything using old libraries fail at new ones, or any new programs fail at old libraries. Probably the same for any stack-size changes (which mudflap probably does).

Re:and how many times... (2, Interesting)

LiquidCoooled (634315) | more than 9 years ago | (#11938134)

Actually, MS are pretty good at that as well.

You can still run software from 1981 on windows XP.

Take a look for yourselves (those in Windows) here [bricklin.com]

Re:and how many times... (0, Redundant)

ceswiedler (165311) | more than 9 years ago | (#11938145)

You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...

Can you run C++ applications compiled on Solaris 2 on any later version?

Re:and how many times... (2, Interesting)

ceswiedler (165311) | more than 9 years ago | (#11938231)

You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...

Can you run C++ applications compiled on Solaris 2 on any later version?

Compatibility is where Sun rocks, and it's also the rock that Sun is tied to. Most of the things that people hate about Solaris are kept that way because of their commitment to backwards compatibility. It becomes difficult to make signifigant changes if you focus on compatibility the way they do.

Linux and other OSS tools like GCC have advanced quickly partly because they have always been able to rewrite just about anything if they need to. Historically people were used to it, or okay with it. I wouldn't be suprised if at some point Red Hat and other Enterprise vendors forked a stable-ABI version of GCC, glibc, and Linux, because in larger environments backwards compatibility is very important.

Why? (1)

oliverthered (187439) | more than 9 years ago | (#11938274)

Most Linux distributions and users have the ability to re-compile everything from source, upgrading to the latest GCC is only a day away for me (the time it takes to rebuild my system).

Designing to last is a different issue, and I think there should be less brackages because the software should be designed properly in the first place.

GUI (0, Flamebait)

stud9920 (236753) | more than 9 years ago | (#11938027)

Come on ! Visual C++ has had an IDE for what, twelve years ? and Borland C++ 15 ?

Open source just does not cut it for any serious developer.

Re:GUI (2, Informative)

Trillan (597339) | more than 9 years ago | (#11938050)

GCC is just the compiler. If you want an IDE that works with it, look around... there are a few. I don't really have any recommendations as I'm mostly working with other tools right now.

Re:GUI (1)

Taladar (717494) | more than 9 years ago | (#11938088)

In Open Source UIs for development are usually not for a single programming language or compiler since the needed features are usually not so different for different languages and why reinvent the wheel over and over again. Oh, I see, to sell courses for the new GUI for 1000 bucks a day...

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11938091)

There are like a dozen GUI/IDEs that can use GCC as the backend compiler, even as a cross-compiler / debugger.

The Eclipse IDE, Source Navigator and KDevelop are just three that come to my mind. DDD and Insight are two popular debuggers that work via GDB.

Check Freshmeat.net / Sourceforge.net for some other IDEs.

Re:GUI (1)

Lisandro (799651) | more than 9 years ago | (#11938094)

Come on ! Visual C++ has had an IDE for what, twelve years ? and Borland C++ 15 ?

This one is quite good... [vim.org]

Ahhh, the old Borland C/C++ IDEs... i recall programming in BC/C++ 3.2, and the IDE was something i really missed when i moved on. Sometimes you felt like you were running QBasic - the debugger was so well integrated...
TASM was nice aswell.

Re:GUI (1)

devphil (51341) | more than 9 years ago | (#11938119)


I believe I speak for all my fellow GCC maintainers when I say: why, exactly, is an IDE our responsibility?

Oh, that's right, it isn't. Piss off, troll.

Re:GUI (3, Informative)

ishmalius (153450) | more than 9 years ago | (#11938136)

Visual C++ does not have an IDE built into the compiler either. Visual Studio is a GUI editor for a VC++ project which shells out to the command-line compiler.

Likewise, there are several IDEs that can nicely handle a C++ project which uses GCC. Eclipse [eclipse.org] is maybe the best example of these.

Besides, do you really want "Must have GUI to cope with compiler" on your resume? ;-)

Re:GUI (1)

man_of_mr_e (217855) | more than 9 years ago | (#11938212)

While it's true that the GUI shells out to the compiler, there are hooks in the compiler to make certain operations more atomic from the GUI perspective. One really nice feature is the ability to pass multiple source files on the command line so that a new process need not be created for each source file (compile one file, exit, spawn new process cycle).

This makes it really easy for the GUI build system to drastically improve performance of the compile. I wish GCC would develop an option to do something similar.

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11938137)

it's a compiler not a gui!!

if you want an ide, try something like kdevelop, emacs, or if you're on a mac, xcode. You can even get it to all integrate with a gui front end to gdb. (GNU Debugger).

Re:GUI (4, Insightful)

Daedius (740129) | more than 9 years ago | (#11938194)

First, you are missing view of an ideaology among many open source projects which is to create a very powerful and optimized that does not bind itself, its users, or any other projects that want to build on top of it to any particular GUI. Most programs do this by running in extremely flexible commandline interfaces, allowing library interfaces, or just being a library for external programs to reference. You do have a point, however, that there is a lacking of a good IDEs in the linux community. I don't think any of us can deny the tremendous effect of an extremely good IDE (Eclipse for java for example). I think within the open source community one of the biggest threats they have to people just picking up linux and wanting to program is a lack of a good IDE. Honostly, when i'm programming in .NET on Visual Studio 2003, I feel like i'm in heaven. I only wish I could have the same type of luxury within linux (Especially with the MONO project!). But with all things, it takes contribution.

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11938239)

Good thing we have unserious developers working on Linux, Firefox et al! Apparently "serious" developers only develop for windows...

Shocking... (0)

templest (705025) | more than 9 years ago | (#11938035)

And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'


I doubt that anyone is going to be rushed to the emergency room for this one.

sane error messages when using templates (4, Insightful)

kharchenko (303729) | more than 9 years ago | (#11938043)

I wish the compiler would output sane error messages on compiling code that uses a lot of templates (i.e STL). At least fixing it so that the line numbers are shown during debugging would be a huge improvement!

Re:sane error messages when using templates (-1, Troll)

noselasd (594905) | more than 9 years ago | (#11938079)

There is a simple fix.
Get the hell away from the C++ madness.

Re:sane error messages when using templates (1)

scotch (102596) | more than 9 years ago | (#11938230)

Is that the suicide solution?

Favorite quote from the article (5, Insightful)

devphil (51341) | more than 9 years ago | (#11938069)


It's not too much of a stretch to say GCC is as central an enabler to the free and open-source programming movements as a free press is to democracy.

If GCC can compile C++, then... (1)

jez9999 (618189) | more than 9 years ago | (#11938083)

... what's the difference between gcc and g++?

Re:If GCC can compile C++, then... (1)

The One KEA (707661) | more than 9 years ago | (#11938127)

g++ is a companion program which adds half a dozen magic switches to gcc and does other magical things to provide extra C++ features that are implemented in the system libraries.

Re:If GCC can compile C++, then... (0)

Anonymous Coward | more than 9 years ago | (#11938185)

Also, gcc stands for GNU Compiler Collection, as well as GNU C Compiler - so there are two "gcc"s out there.

Re:If GCC can compile C++, then... (4, Informative)

Kupek (75469) | more than 9 years ago | (#11938181)

g++ is basically an easy way of calling gcc for C++. From the gcc and g++ manpage:
However, C++ programs often require class libraries as well as a compiler that understands the C++ language---and under some circumstances, you might want to compile programs from standard input, or otherwise without a suffix that flags them as C++ programs. g++ is a program that calls GCC with the default language set to C++, and automatically specifies linking against the C++ library. On many systems, g++ is also installed with the name c++.

Not much. (4, Interesting)

devphil (51341) | more than 9 years ago | (#11938224)


"gcc" will switch languages based on the filename extension. Many people compile C++ by calling "gcc".

"g++" suppresses that bit of logic and forces the language to be C++, which is useful if you have some C code that you want to be built as C++, or if you're feeding the C++ source from stdin (hence, no filename extension).

Linking C++, though, you want to use g++ instead of gcc, unless you really know what you're doing. The "gcc" driver doesn't know which libraries to pull in -- yes, this is something we'd like to change someday -- and the "g++" driver will correctly pull in libstdc++, libm, etc, etc, in the correct order for your linker and your system.

(Hands up, everybody who remembers when "g++" was a shell script!)

Demo (2, Interesting)

pjf(at)gna.org (807061) | more than 9 years ago | (#11938120)

Does anyone have a LiveCD of this stuff? ;-)

Fortran??? (2, Interesting)

CrayHill (703411) | more than 9 years ago | (#11938128)

My guess is that they are using f2c (translating fortran to C first, then compiling), rather than integrating and updating g77. I don't expect this to match most native Fortran compilers for efficiency.

Re:Fortran??? (1)

RWerp (798951) | more than 9 years ago | (#11938247)

AFAIK f2c is a separate project. gfortran is working like g77, it's a frontend to gcc.

Wrong. (3, Informative)

devphil (51341) | more than 9 years ago | (#11938265)


Even the most cursory search of the GCC mailing list archives would disprove this.

More incompatibilities on the way? (2, Insightful)

gvc (167165) | more than 9 years ago | (#11938133)

The gcc team seem to have no respect for legacy code. Incompatible syntax changes and incompatible dynamic libraries make me dread every new release.

Re:More incompatibilities on the way? (4, Insightful)

ari_j (90255) | more than 9 years ago | (#11938206)

It's been my experience that they only have a lack of respect for incorrect code. If your legacy code is incorrectly-written, then you assumed the risk to begin with, says me. Write to the standard.

Re:More incompatibilities on the way? (3, Insightful)

gvc (167165) | more than 9 years ago | (#11938242)

Yes, you've captured their attitude precisely.

Re:More incompatibilities on the way? (1)

multipart (732754) | more than 9 years ago | (#11938261)

And you want to compile your legacy code with the latest-and-greatest compiler...why? If you write code that is standard conforming, then GCC can compile even K&R C without trouble. If you rely on obscure, non-standard features, do not expect them to work. Your fault, not GCC's. Solution: Use an older GCC. They still work, you know.

From what I've heard (4, Informative)

Mad Merlin (837387) | more than 9 years ago | (#11938146)

GCC 4.0 apparently does compile things quite a bit quicker, C++ in particular. This should be a nice boost for anybody who compiles KDE and such for themselves.

If you're interested, here's a (long) discussion [gentoo.org] which makes reference to many of the things coming in the new GCC.

Nitpicking (1)

mike260 (224212) | more than 9 years ago | (#11938150)

A better-established GCC competitor is Intel, whose compilers are recognized to be the gold standard for software running on x86 chips.

Is that actually true? Last time I tried a head-to-head comparison, the Intel compiler came a distant third to GCC and MSVC.

Compiler (2, Informative)

linguae (763922) | more than 9 years ago | (#11938153)

Almost all open-source software is built with GCC, a compiler that converts a program's source code--the commands written by humans in high-level languages such as C--into the binary instructions a computer understands.

Don't all compilers convert a program's source code into binary instructions?

Re:Compiler (1)

sconeu (64226) | more than 9 years ago | (#11938273)

No. Early C++ compilers translated C++ into C.
MATLAB has a compiler that turns MATLAB into either C++ or C.

Latest Fedora-development has gcc 4.0 (2, Informative)

utamaru (702915) | more than 9 years ago | (#11938178)

$ gcc --version
gcc (GCC) 4.0.0 20050310 (Red Hat 4.0.0-0.33)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I've noticed it compiles a bit faster and the binaries are a bit bigger aswell.

Re:Latest Fedora-development has gcc 4.0 (1)

Pop69 (700500) | more than 9 years ago | (#11938220)

You mean RH has shipped another incomplete beta compiler ?

That sounds familiar for some reason.....

Re:Latest Fedora-development has gcc 4.0 (1)

man_of_mr_e (217855) | more than 9 years ago | (#11938241)

I thought Red Hat had learned their lesson with the RH7/GCC3.96 debacle. I guess not.

Gentoo system rebuild! (4, Funny)

uujjj (752925) | more than 9 years ago | (#11938184)

Can't wait!

(I'm especially excited by the possibility of random compiler incompatibilities!)

PathScale... looks interesting... (1)

kompiluj (677438) | more than 9 years ago | (#11938186)

Quote from the article: A start-up called PathScale offers an open-source compiler that's compatible with GCC 3.3. "Our company is trying to be the GCC alternative for people who care about high performance," said Len Rosenthal, vice president of marketing for PathScale [pathscale.com] ..
From this page [pathscale.com] and their claims about GCC front end (source code) compatibility I infer that their compiler is just an back-end (code generator) to GCC using GCC's front-end. I think that writing full C/C++/Fortran front end with GCC compatibility would be no small feat (especially that most big companies use Edison Design Group front-end, developing only their back-ends).
What looks a little bit suspicious are PathScale's performance claims. It looks like the PathScale compiler for x86 generates much faster code than Intel's own in-house compiler (which is being developed by people hired from KAI known for creating a very high performance compiler) or the industry-famous Portland Group compiler. I would be more than happy to see that PathScale's product delivers what is promised.

C++/Java Compiler Comparisons (1, Insightful)

Doc Ruby (173196) | more than 9 years ago | (#11938225)

C++ will be "much faster", so it's now "much slower" than it can be. What about the comparative efficiency of the Java bytecode it will generate? If the Java compiler is already getting more of its maximum theoretical efficiency, doesn't that mean that Java code might be faster than C++? If the Java efficiency isn't as close, doesn't that mean that any comparatively lower performance compared to C++ executables could be overcome by developing the Java compiler further? In fact, doesn't the fact that even C++ compilers as mature as GCC at this late date can get big performance increases with better programming, mean that all the C++/Java performance comparisons are really more about the compiler and its language module optimization?

old languages (0)

Anonymous Coward | more than 9 years ago | (#11938234)

Ada jokes, riiiiight after me !

hmm.... (0, Redundant)

ajaf (672235) | more than 9 years ago | (#11938237)

"And software written in the C++ programming language should run faster--"shockingly better" in a few cases."

What about compilation times?

What about export? (0)

Anonymous Coward | more than 9 years ago | (#11938253)

When is GCC going to support the 'export' keyword? You will never be able to claim to fully support ISO C++ until then.

Decades old? (1, Funny)

pjdepasq (214609) | more than 9 years ago | (#11938259)

If Fortran 95 was released in '95, and it's now 2005, isn't it a decade old language? Let's not get ahead of ourselves here....
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?