| |||||||||||||
gcc 4.0 available
gcc 4.0 has been released. The list of improvements is long - better optimization, more analysis and error checking, and the Fortran 90 compiler everybody has been waiting for. See the changelog for the full list.
(Log in to post comments)
Signed releases Posted Apr 22, 2005 5:14 UTC (Fri) by yem (guest, #1138) [Link] Still no strong signature for the tarballs. What is with these guys?
PS: congrats!
Signed releases Posted Apr 22, 2005 6:43 UTC (Fri) by nix (subscriber, #2304) [Link] Er, the tarballs all have OpenPGP signatures.
(You can't upload anything to ftp.gnu.org and mirrors anymore without that.)
Apologies Posted Apr 22, 2005 8:12 UTC (Fri) by yem (guest, #1138) [Link] Ah so they do. Sorry. ftp.gnu.org was down and the mirror I checked isn't carrying the signatures. All is well :-)
gcc 4.0 available Posted Apr 22, 2005 5:21 UTC (Fri) by xoddam (subscriber, #2322) [Link] Congratulations and thanks to the gcc maintainers. This will be a bigstep forward as it stabilised and becomes a preferred compiler. Though I'm sure some people will go on using gcc 2.95 forever :-)
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 6:27 UTC (Fri) by dank (guest, #1865) [Link] Hey, don't knock gcc-2.95.3.It was a very good release in many ways, and on some benchmarks, beats every later version of gcc so far, up to and including gcc-3.4. (I haven't tested gcc-4.0.0 yet, but I gather it won't change that. I'm hoping gcc-4.1.0 finally knocks gcc-2.95.3 off its last perch, myself.)
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 6:45 UTC (Fri) by nix (subscriber, #2304) [Link] It's when the RTL optimizations start getting disabled that you'll see real speedups. Right now most of them are enabled but not doing as much as they used to, which is why GCC hasn't slowed down significantly in 4.x despite having literally dozens of new optimization passes over 3.x.
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 11:29 UTC (Fri) by steven97 (guest, #2702) [Link] You are making two assumptions that are wrong:1) rtl optimizers will be disabled. It appears this won't happen any time soon. 2) rtl optimizers do less, so they consume less time. I wish that were true. There is usually no relation between the number of transformations and the running time of a pass. Most of the time is in visiting instructions and doing the data flow analysis. That takes time even if there isn't a single opportunity for a pass to do something useful.
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 12:39 UTC (Fri) by nix (subscriber, #2304) [Link] 1) rtl optimizers will be disabled. It appears this won't happen any time soon.I'm aware that you're involved in an ongoing flamewar, er, I mean animated discussion in this area, and I'm staying well out of it :) If the damned things weren't so intertwined they'd be easier to ditch: and indeed it's their intertwined and hard-to-maintain nature that makes it all the more important to try to ditch them (or at least simplify them to an absolute minimum). Obviously some optimizations (peepholes and such) actually benefit from being performed at such a low level, but does anyone really think that loop analysis, for instance, should be performed on RTL? It is, but its benefits at that level are... limited compared to its time cost. 2) rtl optimizers do less, so they consume less time. I wish that were true. There is usually no relation between the number of transformations and the running time of a pass. Most of the time is in visiting instructions and doing the data flow analysis. That takes time even if there isn't a single opportunity for a pass to do something useful.Er, but the compiler's not slowed down significantly even with optimization on. Are the tree-ssa passes really so fast that they add nearly no time to the compiler's runtime? My -ftime-report dumps don't suggest so.
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 18:02 UTC (Fri) by steven97 (guest, #2702) [Link] Most tree optimizers _are_ fast, but not so fast that they consume notime at all. But they optimize so much away that the amount of RTL produced is less. If that is what you had in mind when you said "RTL optimizers do less", then yes, there is just less RTL to look at, so while most RTL passes still look at the whole function, they look at a smaller function most of the time. That is one reason. The other reason why GCC4 is not slower (not much ;-) than GCC3 is that many rather annoying quadratic algorithms in the compiler have been removed. With a little effort, some of the patches for that could be backported to e.g. GCC 3.4, and you'd probably get a significantly faster GCC3. Other patches were only possible because there is an optimization path now before RTL is generated.
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 21:02 UTC (Fri) by nix (subscriber, #2304) [Link] That's what I meant, yes, and it's so intuitively obvious that it amazed me to see you disagreeing. Obviously less code -> less work -> less time!
I didn't mean the RTL optimizers had become intrinsically faster (except inasmuch as code's been ripped out of them).
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 16:03 UTC (Fri) by Ross (subscriber, #4065) [Link] I'm not sure he was talking about the speed of the compiler. I read it astalking about the quality of the generated code. I could easily be wrong though.
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 17:06 UTC (Fri) by mmarq (guest, #2332) [Link] " I'm not sure he was talking about the speed of the compiler. I read it as talking about the quality of the generated code. "
And that is what should matter the most; *The end user*. Because if people complain about the speed of the compilation process they should change to a better computer, perhaps a NForce 4/5 based for Atlhon64 or Pentium4 or the latest VIA chipsets with support for SLI and those Dual Core CPUs coming out soon!...
... he, right!, support for those beasts aren't good enough for Linux right now! But that isn't much different from what was in, say 2001!...
I've no intention to add to any flamewar, but my point is as exposed above that the community trend to discuss heavly on less important issues. The Linux commercial party are battling for scratchs whyle the majority of end users not only dont know, but they dont whant to know, because Linux like Unix is viewed as something for geeks or bearded gurus,..., and worst of all standars go at the speed of a snail, because the philosophy is add features and avoid standards.
There are hundreds of distros but i havent seen one that adds a report of tested hardware configurations(if anyone know one please link it), or care about those, or care about being *religious* about standards, because that is the only way to expose the masses of low tech end users to the same 'methods' and 'ways', for a much larger period of time, adding the change for distros to get very good at the 'interface for low tech users',and in consequence gain a larger adoption percentage.
Open Source community is closing itself inside it's own technical space! And when, if, that happens completly, then it's another Unix story almost like a carbon copy.
Hardware databases Posted Apr 22, 2005 21:16 UTC (Fri) by sdalley (subscriber, #18550) [Link] Novell/Suse makes a reasonable attempt, see the links on http://cdb.novell.com/?LANG=en_UK .
Hardware databases Posted Apr 24, 2005 17:09 UTC (Sun) by mmarq (guest, #2332) [Link] " Novell/Suse makes a reasonable attempt,... "
I've done a search on that site, on 'Certified Hardware' for hardware/software, for the companys ASUSTEK, ECS, EPOX, DFI, GIGABYTE and INTEL with the the keywords "motherbord", and without any keyword which means every piece of hardware.
Since those are manufactores that also do Graphic Boards besides Mobos, they would represent perhaps more than 70% of a common desktop system, and representing perhaps more than 70% of the market, very ahead of the integrators HP/Compaq, IBM, gateway and DELL all put togheter. And Since some of those manufactors also do server 'iron', Mobos or systems, i belive that is represented, perhaps not far from 90% of *all* (server+desktop) deployed base.
The only result i've got was for ASUSTEK showing old Network Servers, and INTEL showing LAN driver(net adpaters), RAID adapters and Network Servers, some aging a lot??!!!
Understanding what line of business Novell is in, still i consider this very far from reasonable... not reasonable even to them if they want to survive in a medium to long term!.
Hardware databases Posted May 8, 2005 5:43 UTC (Sun) by barrygould (guest, #4774) [Link] The lifecycle of desktop/consumer motherboards is so short, and there are so many brands, chipsets, and models, that it is extremely difficult for any software vendor to maintain a comprehensive compatibility list.
FWIW, Dell supposedly often uses ASUS motherboards.
FWIW, I've never had a problem with linux on any motherboard unless it was based on a brand-new chipset for which drivers were just becoming available.
If you're really worried, find out what kernel version is used by a distribution, and see if the kernel.org kernel of that version supports your chipset, etc.
Barry
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 21:36 UTC (Fri) by nix (subscriber, #2304) [Link] The standards-compliance changes in GCC at least (and there have been many) weren't a matter of making GCC reject noncompliant code so much as they were one of making it accept compliant code it'd been wrongly rejecting. I mean, nobody waded into the compiler thinking `Shiver me lexers, what widely-used extension shall I remove today? Arrr!' --- it's more that, say, the entire C++ parser was rewritten (thank you, Mark!), and in the process a bunch of extensions got dropped because they were rarely-used and didn't seem worth reimplementing, and a bunch of noncompliant nonsense that G++ had incorrectly accepted was now correctly rejected, *simply because accepting the nonsense had always been a bug*, just one that had previously been too hard to fix.
(Oh, also, GCC is very much more than `the Linux compiler'. All the free BSDs use it, many commercial Unix shops use it, Cygwin uses it, Apple relies on it for MacOSX, and it's very widely used in the embedded and (I believe) avionics worlds. Even if, with the wave of a magic wand, the Hurd was perfected and Linux dissolved into mist tomorrow, GCC would still be here.)
gcc-2.95.3 was a good vintage... Posted Apr 22, 2005 21:22 UTC (Fri) by nix (subscriber, #2304) [Link] Well in that case he's likely wrong :) Even though the focus of much of the 3.x series was standards-compliance, not optimization, and 3.x didn't have tree-ssa, there have been some notable improvements in that time, like the new i386 backend.
Alas, major performance gains on register-poor arches like IA32 may be hard to realize without rewriting the register allocator --- and the part of GCC that does register allocation (badly) also does so much else, and is so old and crufty, that rewriting it is a heroic task that has so far defeated all comers...
gcc-2.95.3 was a good vintage... Posted Apr 25, 2005 6:38 UTC (Mon) by HalfMoon (guest, #3211) [Link] Alas, major performance gains on register-poor arches like IA32 may be hard to realize without rewriting the register allocator ... Then there's Opteron, or at least AMD64 ... odd how by the time GCC starts to get serious support for x86, the hardware finally started to grow up (no thanks to Intel of course).
gcc-2.95.3 was a good vintage... Posted Apr 24, 2005 20:35 UTC (Sun) by dank (guest, #1865) [Link] Yes, I meant the quality of the generated code.(I care about the speed of compilation, too, but gcc-4.0 is doing fine in that area, I think.)
I'd love to switch to the new compiler, because
I don't need *better* code before I switch,
The whole point of gcc-4.0 is to shake out the bugs
gcc-2.95.3 was a good vintage... Posted Apr 25, 2005 16:05 UTC (Mon) by nix (subscriber, #2304) [Link] Yes, please submit bugs if you find important apps being slowed down!
Strings are now unavoidably constants Posted Apr 22, 2005 11:35 UTC (Fri) by gdt (subscriber, #6284) [Link] The removal of the -fwritable-strings option will flush out any code yet to be moved to ANSI C. It will be interesting to see how much there is. Our user group had an experience this week of a program SEGVing from writing to a string constant. The beginner programmer had typed in example code from a C textbook which was popular five years ago, and was obviously confused and concerned that it didn't work. So not all pre-ANSI code will be old.
Strings are now unavoidably constants Posted Apr 22, 2005 21:39 UTC (Fri) by nix (subscriber, #2304) [Link] The removal of the -fwritable-strings option will flush out any code yet to be moved to ANSI C.I think the removal of -traditional is more likely to do that --- and that happened in 3.3.x ;)
Strings are now unavoidably constants Posted Apr 22, 2005 22:38 UTC (Fri) by gdt (subscriber, #6284) [Link] Sorry, I expressed myself poorly. There's a lot of code out there that is K&R with ANSI function definitions. I'm interested to see how many of these break from this semantic change. I've no idea if it is a little or a lot. It will be interesting to see.
Strings are now unavoidably constants Posted Apr 23, 2005 21:30 UTC (Sat) by nix (subscriber, #2304) [Link] Well, Apple's preserved the option in their tree (used for MacOS X) because they have some stuff they know breaks...
|
|||||||||||||