Home » Forums » Other » Applications and Utilities

Tools: GCC 3.4.0 Released

Submitted by Jeremy
on April 21, 2004 - 8:28am

Mark Mitchell officially announced the release of GCC 3.4.0 saying, "this release contains a large number of new features relative to GCC 3.3.3 as well as over 900 fixes for defects in previous releases." Review the changelog, then download GCC 3.4.0 from a mirror. As for the future of the GNU Compiler Collection, Mark went on to note:

"The GCC 3.4.1 will follow in approximately two months. It will contain only fixes for regressions in GCC 3.4.0 release to previous releases of GCC. The next major release of GCC (whose version number is still undecided) will be released in late 2004 or early 2005."

From: Mark Mitchell [email blocked]
To:  gcc, [email blocked]
Subject: GCC 3.4.0 Released
Date: Tue, 20 Apr 2004 21:44:17 -0700

The GCC 3.4.0 release is now (or will soon be) available from the sites 
listed at:

   http://www.gnu.org/order/ftp.html

This release contains a large number of new features relative to GCC 
3.3.3 as well as over 900 fixes for defects in previous releases.

Visit:

  http://gcc.gnu.org/gcc-3.4/changes.html

for a list of the changes in this release.

The GCC 3.4.1 will follow in approximately two months.  It will contain 
only fixes for regressions in GCC 3.4.0 release to previous releases of 
GCC.  The next major release of GCC (whose version number is still 
undecided) will be released in late 2004 or early 2005.

-- 

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
[email blocked]
‹ .cgi files in html direcoty of apache Tools: GCC 3.4.2 ›

bugs included....

Anonymous
on
April 21, 2004 - 10:00am

It didn't take long to find a bug. :(
gcc bug #15040

heh

Anonymous
on
April 21, 2004 - 2:45pm

Seems to be a kernel bug and not a gcc bug.

Yes and no

Mr_Z
on
April 21, 2004 - 7:41pm

GCC is behaving oddly when presented w/ low memory conditions. It appeared to me when I read the bug that the inliner is crapping out because it can't get the memory it needs. It doesn't help that it's giving a wholly uninformative error message. GCC needs to fix two things to really nail this bug: Reduce GCC's memory footprint, and fix the error message / error handling under OOM.

and another one

Anonymous
on
April 25, 2004 - 4:40am

Here's another one: gcc bug #15114

Cool! Precompiled headers!

Anonymous
on
April 21, 2004 - 10:59am

I realize they consider this to be a technology preview feature, however, it should be interesting to see what impact it makes for compiling code using projects like wxWindows, QT, ACE, etc...

Hopefully there will be some real noteworthy returns.

Ok, what are precompiled head

florin
on
April 21, 2004 - 1:30pm

Ok, what are precompiled headers?
(i think it's better to ask than to try guessing)

I tried googling for "precomp

Prommy
on
April 21, 2004 - 1:57pm

I tried googling for "precompiled headers". First hit was a very good description. *hint*

oh snap

Anonymous
on
April 21, 2004 - 4:42pm

you've been _served_ dude

just a speed up option

auzy
on
April 21, 2004 - 9:17pm

basically, in sourcecode u have 2 things, source files, and header files.. Source files contain all the real code, that does everything, and header files contain code that is normally shared between files, and initialisation stuff for C (like define the data structures etc...

At the moment, if theres 10 different files using bleh.h (a header), bleh.h needs to be compiled 10 different times.. With precompiled headers, you compile it once, and then use that every time.. so u save 90% of that headers compilation time..

So, basically it just speeds up compiling, in cases where the headers are shared, by alot.. If you read the first chapter of a C/C++ book u can learn fully what they are..

Either way, its a bad idea using this option at the moment because u could possibly end up with buggy compiled code..

One great thing about precompiled headers though is it means the standard headers included with C might be able to be precompiled, where in most cases is where u'd get a compile speed increase.

One other good thing about precompiled headers is that if the headers are modified, you dont need to compile every file that uses that header again, which is a massive benefit for programmers, as theres nothing worse then having a hundred source files which can be precompiled, but then modifying one line in a header common to all those files and needing every file to be recompiled again (but that benefit will only affect coders)

precompiled headers

Anonymous
on
April 22, 2004 - 2:03pm

Precompiled headers are new to the Unix world but they have been very commong with Windows compilers. They can greatly increase compile speeds especially if you have large headers included in many files (especially with inline functions and methods in the headers). For non-C++ code the speedup tends to be pretty minor. It can even be a slight pessimization.

At the moment, if theres 10 d

cout
on
April 23, 2004 - 9:09am

At the moment, if theres 10 different files using bleh.h (a header), bleh.h needs to be compiled 10 different times.. With precompiled headers, you compile it once, and then use that every time.. so u save 90% of that headers compilation time..

This is a little misleading. In order to benefit from precompiled headers, the precompiled header must be the first header included in your source file and you may not include more than one precompiled header in a single source file. The down shot of this is that you don't just automatically get this huge increase in compile speed; to really enjoy the benefits of precompiled headers you must design your app to take advantage of them by creating a header all.h that includes headers common to all your source files and then precompiling all.h and including it from each of your sources. This will probably slow compilation on systems without precompiled headers, though.

All of this is described in gcc's documentation on precompiled headers, at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html.

One great thing about precompiled headers though is it means the standard headers included with C might be able to be precompiled, where in most cases is where u'd get a compile speed increase.

You'd only get a benefit here if a standard header is the first header that gets included. Some people believe it's better to include user headers first so that bugs in the headers (such as forgetting to include a header that header depends on) can be found more quickly. If you're one of those programmers, you're likely to not benefit from precompiled system headers.

One other good thing about precompiled headers is that if the headers are modified, you dont need to compile every file that uses that header again, which is a massive benefit for programmers, as theres nothing worse then having a hundred source files which can be precompiled, but then modifying one line in a header common to all those files and needing every file to be recompiled again (but that benefit will only affect coders)

I don't know how gcc implements precompiled headers, but I'd be very surprised if this is true. If my source file uses conditional compilation (#ifdef ... #else ... #endif), and I change a macro in one of my headers that changes which piece of code gets compiled in my source, I would expect my source file to be recompiled.

Precompiled Headers

Anonymous
on
September 10, 2004 - 8:24am

Hi there...i have tried compiling some programs with gcc3.4 and have triend the Precompiled Header feature..
As mentioned by u and many others thats PCH improves the compilation speed... that seems to hold good only for small projects.
I have 2 Projects:
one with 10 cc files and 10 headers
using PCH for this reduces the compilation speed by half.

two with 100 cc and 100 h files
using PCG for this dosent improve the compilation speed at all.

I have triend two approches...
1 having a saperate PCH for each trnslation unit.
2 having a singel PCH for all the cc files.
But nither is useful.

Any suggessions on wats wrong?

Regards
Arun

GCC 3.4 rocks!!!

Anonymous
on
April 21, 2004 - 10:49pm

Hi there!

I just finished compiling GCC 3.4 and the new kernel 2.6.6rc2.
I noticed a huge improvement in startup time of mozilla and openoffice.

GCC 3.4 + kernel 2.6.6rc2 compiled with it rocks!!!! And with
this VM commits from Linus, my box is not swap friendly. Thanks!!! :)

It would be nice...

Anonymous
on
April 21, 2004 - 10:50pm

If you could test this platform with Con Kolivas Staircase Scheduler!!!!!!

Can anyone provide a patch to 2.6.6rc2??? Con is out travelling... :-P

Lets see when he gets back!!!!

The CFQ scheduler is in 2.6.6

Anonymous
on
April 21, 2004 - 11:45pm

The CFQ scheduler is in 2.6.6-rc1/2

Sorry... Not IO scheduler

Anonymous
on
April 22, 2004 - 12:08pm

Sorry, I was talking about the main kernel scheduler,
the one who is responsable to pick a task and run it
for an amount of time, not the I/O scheduler.

So, I was not talking about CFQ, deadline, etc...

I was talking about O(1) sched, staircase sched, etc...

Yes, but CFQ gives also a bet

Anonymous
on
April 22, 2004 - 3:02pm

Yes, but CFQ gives also a better performance. Only activated by:

elevator=cfq

What on earth you talk about

Anonymous
on
April 24, 2004 - 2:23pm

What on earth you talk about which adn what scheduler?didn't you say the cfq scheduler?or the kernel cpu scheduler has a cfq scheduler too?I'm confused?I want to know which scheduler you talk about,have been merged in the 2.6.6rc1/2

Scheduling

Mr_Z
on
April 24, 2004 - 6:03pm

Re-reading the thread above, the I/O scheduler named CFQ was merged into 2.6.6rc2. This has nothing to do with Con's CPU scheduler, named the Staircase Scheduler.

The second poster in this thread was asking for the first poster to retry their benchmark using Con's CPU scheduler (Staircase). Someone else confused it with the CFQ I/O scheduler.

All sorted out?

None of this has anything to do with GCC 3.4.0, by the way. GCC 3.4.0 does have a new instruction scheduler though. :-)

unlikely

Anonymous
on
April 22, 2004 - 6:38am

I find the "huge improvement" unlikely. The start up of the big bloated apps is mostly spent in the dynamic linker. (While improved with 'prelink', it still holds true.) Improving this would require changing glibc. A better optimizer could shave off a couple of percent on it, but not more.

Forgot to say...

Anonymous
on
April 22, 2004 - 12:14pm

That the huge startup improvement occurs when starting the app for
the second time.
With this combination, GCC 3.4 + kernel 2.6.6rc2, the next time
that I start the App, it takes a second less to start than with
my old kernel + old gcc.
So, staroffica took 4 seconds to startup for the second time (after starting it and closing it before).

Mozilla also exibits this stats, second time startup and later startups happen so much early.

_instead_
of 5 seconds.

So, 20% improvement in the next startup.

I think this is related to VM changes in the kernel (+ GCC 3.4)

Thanks!!!

Um

Anonymous
on
April 23, 2004 - 3:32pm

How exactly do you propose that gcc has improved the cached startup time of an application?

There's only one way I can think of

Mr_Z
on
April 24, 2004 - 6:10pm

About the only way GCC 3.4.0 might improve the cached startup time of a C++ application is if it groups all the vtables closer together and all the dynamically-resolved symbols closer together. This would result in fewer dirty pages per run, and may result in better cache reuse run-to-run.

The 'prelink' utility addresses the second part I mentioned above--the dynamically resolved symbols--in a different manner, by resolving them all up front against the current set of dynamic libraries. The prelinked symbols are overridden automagically if a dynamic library changes later. Since most system libraries don't change very often, this results in a huge win on startup. A big part of the win comes from not dirtying pages on startup and incurring the COW penalty.

Does anyone know if the prelink functionality was integrated into the latest binutils? It could be that prelink is the mechanism that's speeding up the start/restart of huge apps.

Thanks

Anonymous
on
April 25, 2004 - 8:09am

Thanks for the 2 responses on this thread.

If you discover if prelink was integrated, can you post in this
forum?

Well...

Anonymous
on
May 6, 2004 - 10:43pm

For one, by all accounts, it seems to generate noticably smaller code. (The last example I saw, 15% smaller.) Smaller programs and libraries would probably mean faster cached startup time. *bah-dum-bum-ching*

cast-as-lvalue extension removed?!

Zombie
on
April 22, 2004 - 1:51pm

The cast-as-lvalue extension has been removed for C++ and deprecated for C and Objective-C. In particular, code like this:

        int i;
        (char) i = 5;

or this:

        char *p;
        ((int *) p)++;

is no longer accepted for C++ and will not be accepted for C and Objective-C in a future version.

Hello?! What's wrong with that construct? I'll have a hard time getting all my code to compile at some point in time in the future!

It is not standard C

Mr_Z
on
April 22, 2004 - 3:00pm

The deprecated example is not valid C. It was a questionable GCC extension to begin with.

Dereferenced pointers are still l-values, and you can generate that pointer with a cast. For the first example, you could do the following:

int i;

*(char *)&i = 5;

The construct is as ugly as the operation it performs, and that's a good thing.



The second example is easier to fix for this specific case. In general, pointer increments across types aren't guaranteed to work, but char* is a special case. The sizeof operator is defined as giving the size of the operand in terms of the equivalent number of chars.

char *p;

p += sizeof(int);

Isn't that the same as: in

Anonymous
on
September 13, 2004 - 6:53pm

Isn't that the same as:

int i;
i = (char) 5;

?

If I'm wrong, I guess you can always:

char c = 5;
int i = (int) c;

i'm just a n00b, anyway

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.