Slashdot Mirror
GCC 4.0.0 Released
busfahrer writes "Version 4.0.0 of the GNU Compiler Collection has been released. You can read the changelog or you can download the source tarball. The new version finally features SSA for trees, allowing for a completely new optimization framework." The changelog is pretty lengthy, and there's updates for every language supported from Ada to Java in addition to the usual flavors of C.
Is it just me or did the jump from version 3 to 4 happen a lot faster than the one from 2 to 3?
Coder's Stone: The programming language quick ref for iPad
Yeah, but does it have a Common Lisp compiler yet?
of the 2.95 -> 3.0 transition.
Not a C coder myself, (sticking mainly to perl).. I've just got to ask, what are SSA trees, and what benefit do they serve?
da w00t. mtfnpy?
Glad to see they are targeting the AMD64 architecture for improvements.
i wonder when debian sid will integrate GCC 4.0...
reading tfa and changelog intrigued me. optimisations aside im curious if this will be better able to thread on the new multi-core systems coming out, as tls has been spotty till 3.3 and glibc 2. maybe native xd support coming soon too?
also, the c++ side makes me feel optimistic about ongoing support, which had been a big problem till 3.4.
yes im x86/64 centric.
The first rule of USENET is you do not talk about USENET.
I guess they couldn't have Apple release it first under the Developer Tools for Tiger :)
I've already downloaded it and used it to recompile Firefox and I must say that gf@fd@k3nl&
NO CARRIER
Unknown host pong.
So I guess its pretty safe to say that this release is for the birds
*ducks*
think you mean gcl. it's not as integrated as gcj or g77 but it doesn't have to be because it's not the full toolchain.
The first rule of USENET is you do not talk about USENET.
I'm one of those crazy people who built Linux From Scratch. I can't wait to figure out what will (won't?) build with GCC 4.0.0. (One thing's for sure... JDK and OOo won't.)
I don't really get what you're saying.
.NET Framework can peacefully co-exist on the same box. If your app is meant to run on 1.1, and not 2.0, it will run on 1.1.
Referenced by ^ - are you talking about System.Text.RegularExpressions?
Also, multiple versions of
This looks suspiciously like spam to me...
Nice troll.
However note (this is for the grandparent to) - it isn't Visual Studio.NET - It's Visual Studio 2005.
Are the GCC high level intermediate representation (RTL is the low level representation).
Thus, SSA for trees means the high level IR in SSA form.
Before 4.0, no optimizations but inlining were done on the high level IR. All of them were done on RTL.
Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?
I'm sure all the contractors loved it! ;)
GCC motto: "What code can we break today?
Correct me if I'm wrong here, but most Linux distributions are still i386 right? It's only the people who use Gentoo who actually compile everything with i686 options right? So, if autovectorization and all the other improvements in GCC 4.0 make binaries massively faster on modern platforms, how long will it be before the major binary based distributions (like Ubuntu) start making i686 the default and i386 an available alternative (like AMD64 is now).
How we know is more important than what we know.
When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.
I can see my Gentoo box sweating now all nervous for the night I get a little drunk and decide to see how this gcc 4 thing works out. heh heh heh.
No, for example:
.NET 1.1 will error out with such errors. I'd love for someone to clear this up, google has been little help, searching the error number, or any other query I can think of.
String* strMyString;
will throw an error, requiring:
String^ strMyStrin;
Not entierly sure why, not sure if it's for all managed objects. I just know that MS's examples, and old CLR code that I know to work and compiles under 2003 with
Why didn't the poster just link to a list of mirrors? I don't want my favorite compiler's source to be unavailable =(
Just about every time I have to rebuild a kernel or build a kernel mod I get my butt kicked by gcc versions. So my questions are?
Anyone know?
XML is a known as a key material required to create SMD: Software of Mass Destruction
VS.NET was a fancy name to get the .NET name out there. Everything .NET about VS.NET 2003 is the same for VS 2005.
Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?
At least the maintainers of the ISO C++ standard did.
GCC motto: "What code can we break today?
Blame the standards committee, not the GCC maintainers.
Right...and it still isn't Visual Studio.NET 2005 - It's Visual Studio 2005. Microsoft dumped .NET from their naming system.
What exactly happened in your childhood?
So your argument has no substance or actual effect on the conversation? Cool.
Lets get compiling!
Click the post anonymously next time.
However, if you're trying to cover ignorance by pretending that it's inconsequential, that's a pretty weak technique. Gee, I hope Linoose releases a new version of Winux soon, so I can run it on my AMB x62.
Why would I post anonymously? I just didn't bother logging in before, but I wanted to get notifications on replies. I'm actually interesting in what changed by removing .NET from the name? You say it's not inconsequential? Anf that last sentence made no sense to me. For fogive my ignorance.
As an aside, I ignored the original post because it was factless - the same limits applied then as apply now.
Haha, and "for forgive" my inability to type.
Hurry up and download your copy now, before the price goes up!
I was simply posting my experience with it. I couldn't even compile one of Microsoft's examples from MSDN that worked fine in 2003. If you get a chance, try to compile the Socket class example. It's the one that choked and died on me. Don't take my word for it.
The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software and GNU/Linux. We have decided to take no action at this time, as we no longer believe that SCO is a serious threat.
For more on the FSF's position regarding SCO's attacks on free software, please read:
http://www.gnu.org/philosophy/sco/sco.html
% gcc -v
../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --host=i386-redhat-linux
Using built-in specs.
Target: i386-redhat-linux
Configured with:
Thread model: posix
gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)
and his dick fell off.
The end.
He was raised by a troll who lives under a bridge.
I, for one, welcome our new Antichrist overlord.
i am interested in the java compatibility. i figure it probably won't do swing, but will it support, or is will it do say gtk/java native. that'd be sweet. i know Qt/kde has had a java bridge for a while, but i really haven't played to much with it. flame java all you want, it's not a geek language. no obfuscated java, no java monks. BFD. sure that'd nix the whole write-once run anywhdere thing. but hell, what a great opportunity to build and test apps under a jre then compile them, to native.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
I use archlinux, which is i686 optimised.
Why i like it? It gives me a nice optimised core, an installer that doesn't baby me, and something i can build a system off of. I'm running on an old pentium2, so i try as absolutely hard as i can to keep the system lean, and avoid compiling wherever possible. Plus there is a good pile of distro-specific documentation, and great support. I'm all over it as my distro of choice.
Waffles rock.
and no gentoo users commenting on how they've already recompiled their entire system with the new optimizations. Or maybe they're just waiting for some free resources to open a browser.
They've been talking about having Objective-C++ in the GCC main branch for years now. There was even talk that 4.0 wouldn't ship without it. Now it's shipped without it and it's still "coming Real Soon Now". Any word on if it's coming any time soon (really)?
...but it's being eaten...by some...Linux or something...
The parent poster is refering to the deprecation of Managed Extensions for C++ syntax in favor of C++/CLI (which is undergoing ISO standardization).
While it is true the syntax has changed (much for the better: templates are now supported in managed C++ code and so are generics, keywords replace ugly __gc, and more), support for the old syntax is still in the compiler (/clr:oldSyntax), and IntelliSense.
However, you will be unable to mix new syntax and old syntax code in the same project without taking some penalties (IntelliSense will break, at the least). The designer will even spit out old syntax code when designing an old form or control.
While the old syntax is definitely on its last legs, the VC++ team was very concerned about not screwing over those (early) adopters of C++ code for the CLR thus far.
A good resource to read up more on the subject would be Herb Sutter's Blog, Stan Lippman's Blog, or any of the other VC++ team member's blogs.
Take this from a former VC++ teammate who left during the Whidbey product cycle (posting AC since I've never bothered to get a slashdot account).
Ducks are not arboreal.
But they do like to hide behind the tree in Duck Hunt.
That's definitely not new.
I am glad that my network is running distcc. Now after I compile the tool chain I can see how many problems I can identify in a weekend. Life is good!
Screenshots anyone? ;)
The OpenBSD crowd had a lot of concerns about bugs in 3.x and performance regressions (in compiling, not in the resulting binaries). I believe Linus shared some of these concerns (don't have a link handy).
OpenBSD i386 is finally moving towards gcc 3.x, as the bugs have been cleared up even if the performance regressions haven't. I'm wondering if 4.x will be even worse, and if it will be justified by producing better binaries. From TFA, it looks like they've added a few features that may improve optimizations. If it's noticeably better they may move to the new version faster.
I will have to play with it to see what it can do.
I rarely criticize things I don't care about.
Does all this extraneous language support make gcc bloated for single-language compilation? Like, could it conceivably work faster and use up less in the way of resources if the different languages were separated into different compilers? I'm only wondering for the case of huge projects with 100+ make operations...
Without automatic vectorization, the performance benefit of compiling for 686 as opposed to 386 is simply minimal. A lot of people have done benchmarks on this, and found out that tuning for 686 with gcc only provides 1-2% improvements in the best case. Keep in mind that current X86 processors execute instructions out-of-order, so instruction scheduling for a specific pipeline is not going to do much (it's very important for in-order machines, though)
The Raven
Sure, OpenOffice.org spends a lot of time at the idle loop compared to say Half-Life, but there are some cases when even a word processor can lag. Faster loops make repeated operations on the most complex documents, such as Writer reflow, Calc recalculation, and Draw repainting, faster. Faster operations make OOo more responsive in general. More responsive OOo makes users happy.
due to the fact that all its c++ shared libraries will now be 40% smaller due to the symbol visibility improvements (i.e., no runtime adjustment needed by the linker for internal-only functions). This translates into a significant speed improvement for all KDE code.
He spent to much time debugging Windows 9x registeries. He became the registery.
That's what happens when you brain blue-screens.
Does anybody have some informal performance benchmarks between 4.0.0 and the last version? (particularly the runtime of the application)
-fweb came with 3.4 and supposedly helped optimize code in general but in 4.0 some things changed and now -fweb is making code slower according some GCC developers, so you don't want to be using it as a CFLAG any more.
Is the autovectorization (for altivec) also present in Apple's version of GCC4? How does the autovectorization interact with code which already contains veclib calls, if at all?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Appears to have had rusty-nail abortion.
They mean this patent owned by this company. What a surprise.
For those who want to know what works and what doesn't: http://forums.gentoo.org/viewtopic-t-176085.html
Are there benchmarks comparing 3 to 4 available? What benefitw would the average user eventually expect from this release? Thanks!
-- IV
http://www.LinuxMedNews.com Revolutionizing Medical Education and Practice.
The different languages ARE separated into different compilers.
Unfortunatly, it seems you have to have SSE or SSE2 to take advantage of the auto-vectorization
Make that "Gentoo". Damned 'n' key...
Are you talking about the new C++-derivative language support? You want std::string, not System::String. Without a qualifier, it will probably want to use the second form.
And yes, you have to use references ( "^" ) for managed types, not pointers. References move by the whims of the garbage collector.
Better get used to it - it is a proposed for ECMA (and later ISO) standardization. The version in the VS.Net 2003 release is basically gone now, swapped out for the iso-proposed version in VS 2005. Benefits include full managed STL support, but unfortunately existing C++ examples will probably require editing before compilation will work.
k4_pacific must be on dial-up. :)
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
So the choice has been:
- -O2 -fweb
- -O3 -fno-inline-functions
(adding -frename-registers or -fno-rename-registers too, as desired)One of the changes in 4.0.0 is autovectorization optimizing.
One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?
Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.
Sample code:
int a[256], b[256], c[256];
foo () {
int i;
for (i=0; i256; i++){
a[i] = b[i] + c[i];
}
}
This is all done in the intermediate representation within the compiler. It's not programmer-visible. Most developers won't know or care. They'll only care about the fact that programs compiled with GCC 4.0 are faster than ones compiled with earlier versions of GCC.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
2) Put an empty spot in the approprate place(s), with #ifdefs - saying "whatever you do, don't goto www.godforsaken.code.xx and get steensgaard.c"... etc.
Of course resultant binaries might only be legal for personal use.
IANAL, but I'd play one one TV, if you paid me!
This issue is a bit more complicated than you think.
There are a hell of a lot more users that depend on GCC then the paltry Apple userbase.
I don't wish to start a flamewar, zealots of both sides please go play elsewhere, but Apple probably has more users than Linux, and every other Unix box combined is probably dwarfed by Linux. If "paltry" applies to Apple then it probably applies to Linux and Unix in general.
You are right about embedded devices though.
... of including a link to the tarball of the source code of a compiler? I wouldn't think anyone who could actually appreciate the differences of a new version would need slashdot to prompt them to try it out...
Notice the lack of an array index. These are true vector operations to begin with, so it is already assumed that the array elements are independent, therefore the log and addition can be parallelized safely.
Escher was the first MC and Giger invented the HR department.
Will named warnings never be impemented? Or numbered? Something that lets me turn off a warning for a particular line of code?
Have you ever tried writing an overflow safe integer class? I have, and I did, but I have to compile everything with -w because otherwise I get 40 pages of "condition will always be false due to limited range of data type". Bleh! If it will always be false, throw it away! I need the check in there for when the type will be a signed int.
Does anyone have a ray of hope? I love most of GCC's warnings, and have always been able to work around them, but in this case there's just no way to get rid of them.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Gentoo has had a GCC 4 ebuild for months now. I've been using it to build my system. If you really really want it, you need to set your package.keywords to -* and also unmask it in package.unmask.
Then be prepared to switch between gcc 3.4 and 3 a lot because many packages, especially multimedia packages, fail to build.
Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.
They always seem to be close, yet it never happens.
What did they compile it with?
From what I've read, GCC 4 is blazingly fast, _AND_ provides dead code elimination (VERY important for windows users).
So, any ideas of how long till the MINGW port is done?
In LISP code, whenever you see a SETQ (assignment) it cries out that the programmer may be lazy or not very good. Good coders know to bind values (LET) rather than change them (SETQ) and treat iteration as recursion.
Of course functional languages have to bite the bullet when munging data structures (SET!). I have no idea how SSA representation handles such cases.
In the pure functional sphere (e.g. Prolog) you have to treat changing an element in a data structure as making an altered clone of that data structure (though there good structural hacks so that altering 1 element in a 100000 element array does not cause the whole array to be cloned).
Worse than functional languages are the linear logics. I'm sure they make a lot of "deep" sense, but there not only can each variable be only assigned once, but also it can only be read once.
is mudflap included in the 4.0 release? I remember an article before 4.0 was release saying mudflap was going to be new in 4.0. Changelog doesnt mention it
I've always thought that "Duck Hunt" was a pretty obscene-sounding name for a game.
if you want something done, do it yourself or keep it to yourself.
sigs are for fools and trolls. no signature is *always* appropriate. you should turn them off in your preferences.
4.0 is even more pedantic than 3.4, or 3.3. Tons of code that has been working for *years* just don't conpile anymore.
And who came up with that idea that files not terminated with a newline should have a warning about it ? Where the hell is that rule in the C/C++ grammar anyway ?
The JDK (for Linux) is and always was built with GCC.
AMD64 Solaris 10 is also built using GCC.
what about stability? Anyone?
and x86_64 compatibility?
3.x versions were very clumsy
sex is better than war!
I really want to use it, it's 6 years old, please somebody implement it! (I'll try after my current project if you like, but you probably don't want my kind of coding going into gcc. Really. I hate OOP and use goto where I feel like it)
I am trolling
you could say: Jerk off! Most of us are males with no time for women, because of heavy gcc-ing :)
sex is better than war!
Cheers,
Ian
I found an odd bug that was posted under pre-5.005 version of perl running on solaris. When you fork, filehandles and locations get carried into the child process when they aren't supposed to. I spent two weeks on this.
Turns out that the problem is with the gcc compiler. Works great if you have the solaris compiler.
I'll be curious to see if gcc4 has managed to fix this bug, it's many years old by now.
I think that stuff like this made the GCC developers to add de -pedantic flag, from de man file:
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++.For ISO C, follows the version of the ISO C standard specified by any -std option used.
Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few will require -ansi or a -std option specifying the required version of ISO C).However, without this option, certain GNU extensions and traditional C and C++ features are supported as well.With this option, they are rejected.
-pedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __.Pedantic warnings are also disabled in the expression that follows "__extension__".However, only system header files should use these escape routes; application programs should avoid them.
Some users try to use -pedantic to check programs for strict ISO C conformance.They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all---only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.
A feature to report any failure to conform to ISO C might be useful in some instances, but would require considerable additional work and would be quite different from -pedantic.We don't have plans to support such a feature in the near future.
Where the standard specified with -std represents a GNU extended dialect of C, such as gnu89 or gnu99, there is a corresponding base standard, the version of ISO C on which the GNU extended dialect is based.Warnings from -pedantic are given where they are required by the base standard.(It would not make sense for such warnings to be given only for features not in the specified GNU C dialect, since by definition the GNU dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.)
"pendantic" is a ironic way of call it.
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
As someone who upgrades major packages even more rarely than once in a blue moon, should I pkgtool uninstall my current gcc installation before unpackaging and installing gcc 4? Or will gcc 4 gracefully install over existing files without problem?
Slashdot requires you to wait longer between hitting 'reply' and submitting a comment.
Well, he's still here, so make that a failed rusty-nail abortion.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Sorry it appears that you were actually correct. You must be one of, well one, people that actually used managed-C++ outside of Microsoft. I was just automatically presuming that you would be talking about C#.
Does anyone know if there is work under way to provide GCC support for Parrot?
I'd love to see gcj compile down to parrot bytecode.
In the course of every project, it will become necessary to shoot the scientists and begin production.
(here) which is probably quite useful if you already know what SSA is and how it applies to trees.
Ben Hocking
Need a professional organizer?
I guess us gentoo users will just have to recompile our systems yet again. Oh well.
Does anyone have a loaded gun handy?
A bad analogy is like a leaky screwdriver.
Does this new GCC have a transparent background?
Outside of any conventional wisdom about using such a new compiler, I would refrain from trying to compile glibc with this newer version of gcc, for glibc will not compile properly.
The issues associated with compiling glibc should be fixed with the version 2.3.6 release, whenever that may be.
I started a brief web site that documents some of the issues of using the new compiler, so check it out here.
Even the Politburo concurs with Process of Elimination http://process-of-elimination.net
I build and tested 4.0.0 against 3.4.3. I'm not a benchmarch expert but nbench byte (a pretty old version) shows that 4.0.0 outputs very binaries compared to 3.4.3. Has someonebody else noticed this?
but if this is the case, and all languages that gcc deals with are parsed into a single "meta" language, then there might be a possibility of working out a more comprehensive way of enabling language interoperability? or at least translation?
Am I the only one who thinks it might be a good idea? I for one would love to see the ability to write bits of a program in a language suited to the task, and then have it translated to the language of the platform I'm working on. I like the idea of using python for mac programs using pyObjC, but every once in a while it would be great to write a utility function in perl, and be able to compile/translate it to C/objectiveC which could then be accessed directly from the cocoa GUI or re-edited in the native syntax. personally I would like to spend more time working in lisp, and if that could be dealt with in this sort of way, it would be bliss.
How many people here have never said, "Damn, this bit would be so easy if I could write it in _______!" (or words to that effect.)
-- it's ridiculous how many people misspell ridiculous... (damn, damn, damn...)
I *just* ran out of mod points. I'd like to see that kick ass UI written using Core Foundation (you can't use CF alone for app development). You definitely will need Obj-C++ for any sort of serious development (say, if you want to use Boost). Grandparent is either very clueless or a very good troll.
I'm sure this is the last thing on anyone's mind, but for those of us who use ffdshow, this is nice news.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Thanks for the information, I know I was off topic, and damn near trollish(and I was AC because I didn't bother logging in, wasn't at home), but it's good to figure out what was going on. I'm admittedly very new to CLR, and aspects of managed C++, especially this emerging stuff.
No need to wait for system resources. Just do anything cpu intensive like compiling or video encoding with the assistance of your friendly neighborhood "nice" command.
Setting the niceness high means the program in question will allow other programs (like the web browser) to "cut in line" in cpu usage.
Set the niceness high enough, and your program will chug along slowly and use resources as available (very little if you have lot of stuff going; pretty much full if you close stuff down) thereby not bringing your system to a crawl...
It should however be noted that programs used this way will finish last with girls.
Akarsz Magyar Gentoo fórumot? Akkor
Akarsz Magyar Gentoo fórumot? Akkor
oops, need to start again...:
.1321 12.231 ..123
[...]
12.23 321.321
321.23 121.12
321.23 32.123
12.321
invalid number: incomprehensible list input
last format: list io
lately reading direct formatted external IO
Aborted
We have been using the intel fortran compiler in our lab for several years because g77 lacked autovectorization. Has anyone compared the performance of code vectorized with gcc 4 to the same code compiled with ifort? As noted previously the speedup from vectorization can be quite large (with ifort at least).
My code doesn't compile on 3.0 because it contains 2.95 specific work code, because 2.95 didn't support the C++ as I wanted to use it. So I was forced to use the 2.95 bugs to work around the lack of support for the language.
Seriously, 2.95 really sucked for C++. You could make it work, but don't try to do anything tricky. (Though when 2.x was released nothing was very good at C++, 2.x just hung on a lot longer than the competition) Gcc 3.x isn't perfect and I suspect 4.0 will not be perfect either. Gcc 3.0 is a lot better for C++ than 2.95.
They could have delayed implementation of parts of the standard, the standards committee doesn't have any power. There should be a period of years where anything that wasn't flagged is at least flagged as a warning before being flagged as an error.
A programmer should be able to *know* his code is going to break within a certain time, and if he still does it, his fault.
So yeah, I blame GCC. I wrote code that generated no errors. Ported it over to a system whose compiler was 1 year newer, and it wouldn't compile. That's bad. That's dumb.
One of the original differences between Mandrake and Redhat was that Mandrake compiled everything for Pentium while Redhat was still compiling for 386 or 486.
The net will not be what we demand, but what we make it. Build it well.
I have not done any tests myself nor do I have any numbers to compare. However my guess is that for GCC 4.0, vectorization will still be quite behind the Intel compiler. You should see vectorization support in GCC 4.0 as the first skelleton, but a lot of the vectorization stuff didn't make it for GCC 4.0 and is now scheduled for GCC 4.1. For more details see the following web page: http://gcc.gnu.org/wiki/GCC%204.1%20Projects
Marcel
1. The standard isn't static. 2. That's the point of warnings. If it will be an error within the next few years, it should be a warning now.
One can hardly blame the compiler vendor, as we can't expect a compiler to mindlessly maintain backwards compatibility with every weird use of a bug and every bizarre code construct that has ever been supported in the past.
Yes we can. It should be supported without flagging errors but with warnings for quite a while before previously unwarned code is broken.
The ability to compile code written for GCC in another compiler is a *good* thing.
Yes, it is. Conversely, the inability to compile code written in GCC using GCC is a bad thing.
If it requires informing the programmer that their code has always been broken
It wasn't broken. It worked quite well. It compiled. It didn't even get flagged as a warning. If the behavior was so bad (and it wasn't!) then it should have been flagged as a warning at least in the last version.
A little inconvenience is a small price to pay for standards compliance
Not when 1) it isn't a little, 2) it's unnecessary, and 3) it was avoidable. Blind and immediate implementation of standards isn't a virtue when it breaks backward compatibility. If you're a programmer, ask your boss if it's OK that you change a function upon which every program depends in a way that will break compatibility. See how far that gets you. There's a reason.
or should we expect that the GCC authors "embrace and extend" C and other languages
Actually, that's what they're basically doing. They're embracing NEW standards too quickly and breaking good code. I'm not suggesting they do anything that wasn't ever part of a standard - I'm suggesting they delay standard implementation, basing errors off the old standard and warnings off the new. Best of both worlds.
until so much code relies on weird GCC nuggets that programmers (and users) are "locked in" to using just that compiler?
It's better now when not only are you locked in to a compiler, you're locked in to a specific *version* of a compiler?
Maybe I am missing something. If so, please enlighten me (This is not a sarcastic remark--I haven't done much research on what 4.0 has broken so I may be way out of line).
Not taken as such - what you're missing is that when you're maintaining a large project, that sort of behavior on behalf of your compiler is NOT acceptable, particularly in a corporate environment. No company will trust GCC if absolutely no backward compatibility is guaranteed, as managing legacy code is a reality, and rewriting it all isn't an option. Anything that will be flagged as a warning in the future should be flagged as a warning for quite some time. Particularly when the new "errors" are in large part stylistic.
Anyone who doesn't contribute code themselves should be greatful (or at least appreciative) of their efforts, even when they do make mistakes.
1. They do good work. 2. Appreciation doesn't mean silence, and it doesn't mean no suggestions. 3. These "mistakes" are intentional design decisions. Note I'm not jumping them for any bugs (if there are any). I'm suggesting that they need a new direction if they would like any sort of adoption of GCC for more mature applications involving codebases that will be in active use for more than a year.
BTW ... a language like Fortran, that doesn't have pointers at all, is much easier to vectorize; that's one of the reasons a lot of scientific codes are still in Fortran.
Fortran has had pointers for fifteen years now (Fortran 90).
However, they're much more limited than C pointers--by design, not by defect. And you've hit the reason, too: it allows stronger assumptions to be made when optimizaing that can be made with C.
hawk
Well, it's a shame then, that GCC 4.0 cannot even compile KDE. It miscompiles it.
Yes, GCC obviously will never fix that bug. Oh whoa is KDE! Those GCC meanies make KDE go breaky-breaky!
Apple's site says this is packaged with Tiger. Did they get an early release of it?
----
All of whose base are belong to the what-now?
because it does not generate relative addressing via the Procedure Linkage Table (PLT) for internal (non-exported) functions. But you probably know that already, being an apparent GCC expert.
This h0t plck has already doubled, and may do so again by tomorrow! Call our co-conspirators, err, representatives to buy now!
hawk
If MS hadn't have invented it then you wouldn't have known about it and it wouldn't have been in GCC anyway!
Welcome to our world of pain.
If you (the general "you", not specifically Alioth) ever wonder why we occasionally seem to not care about y'all's complaints, this is largely it. We can either get bitched at by you, or we can get bitched at by that other guy, but since neither you nor he contribute to the code, to the bug testing, or even to the discussion, it's all the same to us: inevitable undifferentiated noise. It's not official GCC policy, it's just how it works out.
Now, complaints from people who are actually making an effort to help -- those get our attention, awfully damn' fast.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The Objective-C++ folks had to learn a couple hard lessons about contributing to open source projects, and GCC in particular. So it didn't make it into 4.0, but probably will for 4.n, where n is a very small integer.
In that respect, ObjC++ was no different from any of the zillion other "features" that get thrown at the GCC maintainers: it committed the heinous sin of not magically implementing itself. GCC tends to get this a lot from a user community (which might be large, or might only be a handful of people), and it almost always follows this general pattern:
User Community: Feature X would be cool, plz add it to GCC kthxbye.
GCC: No. We're busy. You can write it yourself, though; here's how and here's why.
UC: But it would be work!
GCC: That's why we're busy. We're either volunteers (so you can't force us to work on what you think would be cool), or we're paid by our employers to work on specific tasks.
[time passes]
UC: Okay, here's a patch.
GCC: Who are you?
UC: We're the people who want feature X. We went off and wrote it on our own, in isolation, because you wouldn't drop your own tasks to do it for us. Now here's the patch, kthxbye.
GCC: This patch is teh suck. People who aren't using feature X are being penalized with (slower compiler, slower generated code, false positive diagnostics, overly strict dependancies, genital warts, etc) to support your smaller user base. You need to work with the maintainers, not dump a patch in their laps out of the blue and expect to have it included.
UC: You're a bunch of fucktards for not accepting our crappy patches!
GCC: What, insulting us is going to make us change our minds?
UC: Fine, we'll fix up the patch so it won't suck.
GCC: Good. Here are some tips: [...] Now, the new version goes out next week, and after that we'll have more time to help.
UC: But this has to go out now!
GCC: It ain't done yet.
UC: But a lot of people want it!
GCC: So? It's not a popularity contest. It. Ain't. Done. Yet. If there are a lot of people who want it, as you claim, then you should have no trouble getting people to help you.
UC: But-
GCC: No. We're not shipping untested half-assed crap. Made that mistake before, we're not doing it again, you'll thank us later.
[time passes]
UC: Here's a patch.
GCC: We'll review it as soon as we can.
UC: Why not now?
GCC: There aren't enough of us. Sucks, doesn't it?
UC: Damn straight...
[time passes]
UC: Looked at the patch yet?
GCC: No. *looks at patch* Good. *commits patch* UC: *faints*
Being smart people, the Objective-C++ community didn't suffer from the immature stages featured in my one-act morality play above. But they got stuck for a while at the "we have a patch" / "that patch sucks" stage, and no progress was made for a long time. By the time the hard bits were worked out, it was too late for 4.0.
i686 + SSE (+ optional SSE2 (+ optional SSE3))
Please to kill MMX, 3DNow!, ASCII instructions, useless instructions,....
open4free ©
Just downloaded an upgrade patch from 3.4.3 to 4.0.0 from the PPR at http://ibiblio.org/sdelta
Must contain much good new code in 4.0.0 since the patch only saved 71.7% over downloading a full bzip2 tarball of gcc 4.0.0
The PPR's patch is 12.5M smaller than the the 21M bzip2 diff patch avaialble from ftp://ftp.gnu.org, creates the gcc-4.0.0.tar with the same md5sum and sha1sum as the official tarball, and the PPR can make on the fly upgrade patches from even older gcc versions like 3.4.2 and 3.4.1 to 4.0.0. Now that is easy upgrading, not to mention fast downloading.
For sometime I was wondering what all this fuss was all for...
On the 4th week of April, which is the 4th month after 2004, Qt4, KDE4, GCC4 were announced
one after the other.
Soon, after I was able to download GCC4, in less than 4 hours at a nice speed of 4 KB/s connected at 44.4 kbps!
Which only took another 4 hours to compile it using my Pentium 4 running at 2.4 GHz, using only 44.4% of my CPU.
That's really nice, since in 4 months I will be able to get the final version of Qt 4.
Unfortunately, like the beta2 of Qt 4, that will also take another 4 hours to compile using my Pentium 4.
Nevertheless, 4 months after the release of Qt 4, we should see the beginning beta of KDE libs 4,
which will essentially lead 4 months after that to a shinny new KDE 4,
around April 4th that will be able to run on the new stable Linux 2.4.34,
which will replace my current Linux 2.4.24 that has an uptime of nearly 4 months.
Isn't that great ?
Now, can someone tell me what this comment was all for ?
The only clue, I can give is all those 'not in the club' buddy,
which are using Gnome 2.6 on Linux 2.6.6 using gcc 2.96 right here in 2006,
waiting for the next beta release of Perl 6.
Thinking that there all cool and sexy!
Or he was the mother.
One thing that amazed me about Fortran 95 pointers is how big they are. On a 32 bit x86 machine, a pointer to an array in HP/Compaq/DEC's Fortran compiler is 32 bytes long (that's bytes, not bits). With all that extra sludge in there, the compiler damn well better be able to optimize things.
Everbody can download an early release from the cvs archive whenever he or she wants. As soon as 4.0.0 is released you can start downloading 4.0.1.
A big part of the reason for going to 4.0 instead 3.5 is that the ".0" hopefully will be a big clue that this version had an entirely new middle end, and thus the potential for tons of breakage.
pretty much every compiler around goes through the following steps: (a) make an abstract syntax tree from the source code, (b) optimize it, and (c) output machine code.
I'm not 100% sure about its internal processing, but I believe tcc either skips some of that or has it all so blended together that the steps aren't very distinct.
it's far more useful to support tons of languages at little extra effort than to drop all alternate languages for a minor performance gain.
In the case of tcc, the design and lack of extra functionality (or admittedly even complete standards compliance) provides a huge speedup at compile time. It's almost shocking to see it blast through code when you're used to working with a recent gcc.
It's so fast that for small programs it can be used as a loader to compile and run C code as if it were a scripting language, with no discernable startup time. Consider that tcc has demonstrated booting a Linux kernel from source in 15 seconds.