Linked by Eugenia Loli on Thu 21st Apr 2005 19:15 UTC, submitted by J@F
General Development GCC 4.0 was released yesterday. Read all about it.
Order by: Score:
v w00t!
by Mike on Thu 21st Apr 2005 19:19 UTC
precompiled headers
by Omega on Thu 21st Apr 2005 19:20 UTC

They were promised for 3.4 but don't work in 3.4. Do they work now?

:-)
by vp on Thu 21st Apr 2005 19:20 UTC

a wonderful day for the free software movement!

little bit broken.
by Anonymous on Thu 21st Apr 2005 19:25 UTC

The package is broken.

If you try compiling it in the same gcc-4.0.0 dir doing a make bootstrap then you end up in errors.

You need to untar gcc-4.0.0 and then create a new dir named gcc bysides it and then enter the gcc dir and from within there.

../gcc-4.0.0/configure --prefix=/usr
make bootstrap

There are a few other errors comming up too but it continues compiling anyways stuff missing etc.

Optimization of generated binaries
by Anonymous on Thu 21st Apr 2005 19:33 UTC

Before we get a bunch of complaints about the fact that most binaries generated by GCC 4.0 are only marginally faster (and some a bit slower) than those compiled with 3.4, let me point out a few things that I've gathered from casually browsing the GCC development lists. I'm neither a GCC contributor nor a compiler expert.

Prior to GCC 4.0, the implementation of optimizations was mostly language-specific; there was little or no integration of optimization techniques across all languages. The main goal of the 4.0 release is to roll out a new, unified optimization framework (Tree-SSA), and to begin converting the old, fragmented optimization strategies to the unified framework.

Major improvements to the quality of the generated code aren't expected to arrive until later versions, when GCC contributors will have had a chance to really begin to leverage the new optimization infrastructure instead of just migrating to it.

So, although GCC 4.0 brings fairly dramatic benefits to compilation speed, the speed of generated binaries isn't expected to be markedly better than 3.4; that latter speedup isn't expected until later installments in the 4.x series.

re: little bit broken.
by Anonymous on Thu 21st Apr 2005 19:33 UTC

> The package is broken.

> If you try compiling it in the same gcc-4.0.0 dir doing a
> make bootstrap then you end up in errors.

Gcc has always been that way. Same deal with glibc.

re: re: little bit broken.
by Anonymous on Thu 21st Apr 2005 19:38 UTC

> Gcc has always been that way. Same deal with glibc.

Well I usually made quite good impressions with gcc..

untar'ing
cd'ing
./configure --prefix=/usr && make bootstrap

Usually worked like a charm but this time its quite broken. If you use SRCDIR == COMPILEDIR then it fails but if you create a different dir besides it SRCDIR != COMPILEDIR then it works, though I detected a bunch of error 1 failures in some of the subcomponents that get compiled, while the compile proceeds the stuff that failed stays failed (from the quick looks it looked like some documents or so).

Now the people spent so much time in creating gcc 4.0.0, even announced RC1 and RC2 but still they rushed it out in an urge and hurry without proper testing.

Thats sadly a bit disappointing.

GCC Optimizations
by Jim Morrison on Thu 21st Apr 2005 19:42 UTC

To correct a note above. In gcc 3.x the optimizations were all done at the RTL level, which is something that looks lispish, but is very close to the assembly for a given machine However, with GCC 4.x and up there are optimizations done at the tree level, which looks more like the programming language and optimizations done at the RTL level, which is more like the machine the code will run on.

Re: re: re: little bit broken.
by anonymous on Thu 21st Apr 2005 19:46 UTC

Read the installation docs,
YOU ARE SUPPOSED to use
OBJDIR != SOURCEDIR.
If you don't do that, you are on your own.

Standard conformance?
by Mark Ping on Thu 21st Apr 2005 19:51 UTC

So how well does this GCC conform to the C++ standard?

Re: Re: re: re: little bit broken.
by Anonymous on Thu 21st Apr 2005 19:54 UTC

> Read the installation docs,
> YOU ARE SUPPOSED to use
> OBJDIR != SOURCEDIR.
> If you don't do that, you are on your own.

There should then be a proper check for this like in glibc, advising one to use OBJDIR != SRCDIR, after compiling gcc OBJDIR == SRCDIR for years I expect it to work out of box as it should work out of the box anyways. OBJDIR != SRCDIR are usually only required if you want to build multiple instances of the same tool from within different directories. But otoh why are other errors there ?

re: little bit broken.
by aegrotatio on Thu 21st Apr 2005 20:32 UTC

OBJDIR is not supposed to be the same as SRCDIR for ages. I'm sure you never bothered to read the installation docs, and probably didn't know to use "make bootstrap". You probably didn't even compile the stage? compilers with optimizations, either.

How long
by CaptainN on Thu 21st Apr 2005 20:44 UTC

How long until some distro uses this? (like Ubuntu)

re: re: little bit broken.
by Anonymous on Thu 21st Apr 2005 20:45 UTC

> I'm sure you never bothered to read the installation
> docs, and probably didn't know to use "make bootstrap".

The last time I read the Installation manuals it was advised to configure, make bootstrap and make install the stuff. I don't see that anything else is required here. There is no need to compile a special stage or even add extra optimizations. What worked perfectly for the past 9 years should still work. I think it's you who requires proper reading of the manuals and not me.

speed speed speed ???
by Omega on Thu 21st Apr 2005 20:48 UTC

how fast does it compile compared to previous releases and other compilers?
how fast does the final code run?

Re: re: re: little bit broken.
by anon on Thu 21st Apr 2005 20:53 UTC

Citing from gcc/doc/install.texi

First, we @strong{highly} recommend that GCC be built into a
separate directory than the sources which does @strong{not} reside
within the source tree. This is how we generally build GCC; building
where @var{srcdir} == @var{objdir} should still work, but doesn't
get extensive testing; building where @var{objdir} is a subdirectory
of @var{srcdir} is unsupported.

No further comments.

Re: re: re: little bit broken.
by Anonymous on Thu 21st Apr 2005 21:06 UTC

> No further comments.

I was up to quote the same. And now read your own stuff what you have quoted:

> This is how we generally build GCC; building where
> srcdir == objdir should still work

From your own quote!!!!! While it might not be exessively tested and not supported its still mentioned that it should work.

As you read in the further quote that I made it's still the old game.

tar xfjv gcc-4.0.0.tar.bz2
cd gcc-4.0.0
./configure --prefix=/usr
make bootstrap && make install

Even this is written in the further installation instructions as it was for the past years. I don't need to compile some steps magic and other stuff and since I want to compile a native compiler for my own host system instructing make bootstrap is all there is.

Now go back in the corner and stop playing the expert. You obviously aren't.

;-----------

And now from further quote:

Installing GCC: Configuration

First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.

Installing GCC: Building

Now that GCC is configured, you are ready to build the compiler and runtime libraries.

Some commands executed when making the compiler may fail (return a nonzero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored.

Building a native compiler

For a native build issue the command make bootstrap. This will build the entire GCC system, which includes the following steps:

RE: How long?
by Anonymous on Thu 21st Apr 2005 21:19 UTC

Well, Fedora is using it in their next release which will be out June 6th.

v Lazy journalism
by Charlie on Thu 21st Apr 2005 21:35 UTC
Re: re: re: little bit broken
by Anonymous on Thu 21st Apr 2005 21:40 UTC

lighten up people ;)

IIRC gcc is gnu software and accordind to the GPL:

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

I guess that includes this unfortunate incident with the compilation process ;)
.

anyway, have a nice day ...

... and if it doesn't work the way you want it, fix it.

Re: Re: re: re: little bit broken
by Anonymous on Thu 21st Apr 2005 21:42 UTC

> guess that includes this unfortunate incident with the
> compilation process and if it doesn't work the way you
> want it, fix it.

Kalispera, while you are right it's still a bad excuse.

link to a binary... again
by bact' on Thu 21st Apr 2005 21:43 UTC

would be great if the link is for a release note, not a binary download!

cheers,

v RE: link to a binary... again
by MegaPouikofTheWeb on Thu 21st Apr 2005 22:25 UTC
v RE: Anonymous (IP: ---.otenet.gr)
by Bryan on Thu 21st Apr 2005 22:36 UTC
Dang me
by Smartpatrol on Thu 21st Apr 2005 22:37 UTC

Can't get it to compile on NetBSD 2.0.2 following the instructions given..not too surprised though i have found there are almost always steps and dependecies left out the documentation. Ever try to get abiword to compile on a NetBSD system...what a hoot.

v Could someone SPELLCHECK submissions please?
by joe on Thu 21st Apr 2005 23:05 UTC
RE: Dang me
by lars on Thu 21st Apr 2005 23:20 UTC

How do you do when you fail to compile abiword on NetBSD?

Since you seem to be a "non-developer" I assume you are using pkgsrc from one of the quaterly branches, which are stable and known good. Especially on i386, since it is the most used platform.

If you are not using pkgsrc, please explain why. It is the preferred way in NetBSD to get third party software installed, you know.

i386 distros
by QuantumG on Fri 22nd Apr 2005 02:12 UTC

hmm.. kinda makes you wonder when Ubuntu is going to move support for 486 and Pentium 1 machines into a seperate distribution so the rest of us can get the benefit of an i686 compiled distribution. With the autovectorization in gcc 4.0 we should see some serious speed improvements.

Autovectorization
by Seo Sanghyeon on Fri 22nd Apr 2005 02:42 UTC

QuantumG, I think you need to wait for 4.1 to see "serious speedup" from autovectorization... Read:

http://gcc.gnu.org/projects/tree-ssa/vectorization.html#status4.0

That's what actually went into 4.0. Other stuffs should wait.

RE: How long
by Mike Douglas on Fri 22nd Apr 2005 02:59 UTC

GCC 4.0 is a release goal for Breezy Badger (the next Ubuntu release).

Objective-C++
by paul on Fri 22nd Apr 2005 03:03 UTC

I recall hearing a rumor that GCC 4 was supposed to finally get the Apple patches to allow Objective-C++ (Objective-C and C++ in the same function.) I didn't see that anywhere in the change list.

That could be a pretty big deal for GNUStep: not only does it make Objective-C much more powerful and much easier to use, but it improves portability between OS X and everything else (since Cocoa has had it from the beginning.)

@paul and @QuantumG
by Matt on Fri 22nd Apr 2005 03:22 UTC

I don't think the autovectorization stuff in 4.0 is really going to affect much. Look at all the enhancements to it going into 4.1:
http://gcc.gnu.org/wiki/Autovectorization%20Enhancements

ObjectiveC++ is not in 4.0:
http://gcc.gnu.org/wiki/What%20will%20be%20in%204.0
Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. (Update) Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.

Re: Matt (IP: ---.reshall.k-state.net)
by CaptainPinko on Fri 22nd Apr 2005 04:30 UTC

any word on what "horribly awry" entails?

@CaptainPinko
by Matt on Fri 22nd Apr 2005 05:57 UTC

No idea.

RE: precompiled headers
by René Rebe on Fri 22nd Apr 2005 08:34 UTC

Worked for me in 3.4.

RE: Dang me (@ lars)
by Geert Hendrickx on Fri 22nd Apr 2005 08:53 UTC

How do you do when you fail to compile abiword on NetBSD?

Since you seem to be a "non-developer" I assume you are using pkgsrc from one of the quaterly branches, which are stable and known good. Especially on i386, since it is the most used platform.

If you are not using pkgsrc, please explain why. It is the preferred way in NetBSD to get third party software installed, you know.


Maybe because GCC 4.0 is not yet in pkgsrc? Anyway, the pkgsrc developers themselves also have to build things outside pkgsrc the first time(s).

If gcc/abiwords buildsystem is not self-contained (missing dependencies), then that's their developers fault, not the pkgsrc/users fault.

I want whole program analisys!
by verbat on Fri 22nd Apr 2005 09:51 UTC

too bad they don't do it yet :/

Worked for me in 3.4.

You are lucky then.

Here is an extract from the offical GCC 3.4 page at http://gcc.gnu.org/gcc-3.4/changes.html :

There are some known defects in the current precompiled header implementation that will result in compiler crashes ... Therefore, precompiled headers should be considered a "technology preview" in this release

And indeed I experienced those crashes.

So I really hope that precompiler headers work in 4.0 !

Advantages of the other free C/C++ compiler
by theuserbl on Fri 22nd Apr 2005 10:41 UTC

Hi!

Do anybody know the advantages of the other free C/C++ compiler over the GCC?

I mean for example
- Tiny C http://fabrice.bellard.free.fr/tcc/
- TenDRA http://www.tendra.org/
- The BSD-Compiler for FreeBSD, OpenBSD und NetBSD
- under Windows OpenWatcom http://www.openwatcom.org/
- under 64bit Computer on Linux Open64 http://open64.sourceforge.net/

I think, some advantages will the other compiler have. Otherwise nobody would working longer on the other compiler and all would working together on GCC.

But which are the advantages of the other free Compiler? Do anybody know more about it?
Have anybody performancetests and so?

Greatings
theuserbl

little off topic
by kaiwai on Fri 22nd Apr 2005 10:54 UTC

It would be nice to know what the Apple GCC 4.0 includes - did they merge and work on the autovectorisation for the PowerPC seperately, and will have those changes merged in at a later date (at GCC steering committees discretion)? I'm curious as to whether the GCC 4.0 improvements that Apple has instore will be noticeable from regular use.

Tiny C
by Seo Sanghyeon on Fri 22nd Apr 2005 11:10 UTC

theuserbl, I don't know about others, but Tiny C's advantage is clear. It's FAST: about or more than 10 times faster than gcc without optimization, and still generates reasonably good code.

I have a program that generates rather large and messy C code (several megabytes), and TCC really helped in reducing edit-compile-run cycle.

BSDs use gcc
by - on Fri 22nd Apr 2005 11:58 UTC

"The BSD-Compiler for FreeBSD, OpenBSD und NetBSD "

BSDs use gcc.

GCC 4.0 improvement for C++
by Richard Stellingwerff on Fri 22nd Apr 2005 12:00 UTC

I've tried it on Fedora Core 4 test 2, and their GCC 4.0 build was able to compile C++ code quite a big faster than GCC 3.3. Hopefully precompiled headers work too, so developing C++ apps on Linux will be fun again.

RE: Advantages of the other free C/C++ compiler
by nxt on Fri 22nd Apr 2005 13:24 UTC

Last time I checked, tcc allowed two things gcc does not
* use #!/usr/bin/tcc (script interpeter) line on the top of the source code -> writin small "scripts" in C

* supported runtime boundary checking.

RE: Advantages of the other free C/C++ compiler
by Anonymous on Fri 22nd Apr 2005 14:24 UTC

#! is used only in interpreted languages, perl python bash.
gcc is a compiler, so no way to use it as an interpreter, why mixing compiler with interpreter? and really i see no advantages to use c as scripting language, seeing how low level is.
example, i prefer to learn perl and use its regex tools than script a c regex by hand.
according to me script c is misleading, in fact csh is no more wide used.

RE: Advantages of the other free C/C++ compiler
by MORB on Fri 22nd Apr 2005 14:26 UTC

"supported runtime boundary checking."

GCC 4 now support that with libmudflap, as well as memory leak checking, uninitialized memory accesses, etc.
See http://gcc.gnu.org/wiki/Mudflap%20Pointer%20Debugging

...
by Anonymous on Fri 22nd Apr 2005 14:53 UTC

Is there a version for win32?

Re: ...
by MORB on Fri 22nd Apr 2005 15:18 UTC

As usual, there will be a win32 version running with cygwin (http://www.cygwin.com) and with ming (http://www.mingw.org).

You can install cygwin or mingw/msys and build it yourself if you don't want to wait until they release the binaries. MinGW is better if you want to do native windows development, as it provides the required headers to access the win32 api and doesn't require a non-commercially redistributable dll at runtime.

@ QuantumG
by voidlogic on Fri 22nd Apr 2005 15:42 UTC

You can select the 686/k7 etc optimized kernel from the package manager. By shipping with 383 by default they allow a great range of possible users

Got it
by Smartpatrol on Fri 22nd Apr 2005 21:54 UTC

Got it to compile just fine. I had to compile it in a directory other than the root of the source. I compiled iton FC2 and NetBSD without issue and already recompile a few programs i use for server duties just for fun.

Re: Standards Conformance
by Solar on Wed 27th Apr 2005 08:05 UTC

@ Mark Ping:

> So how well does this GCC conform to the C++ standard?

They *still* didn't bother to implement 'export', so you still have to write templates in the header files instead of just declaring them there.

They claim that "no-one" requests that feature, which might be because *all* compiler vendors (except EDG) blissfully ignore that this has been part of the standard ever since 1998 - lest users actually demand it being implemented.