I've explained it in a sibling post just now. I was hoping to encourage people to go look up the discussions themselves, but if it's easier to accuse me of slander, so be it.
No, here it is.
on
GCC 4.0 Preview
·
· Score: 4, Informative
I didn't go into details because this has been covered elsewhere, and I'm tired of discussing it myself. But I didn't realize I would be accused of "uninformed slander". So. A bit of background info first.
Inside the guts of the compiler, after the parser is done working over the syntax (for whatever language), what's left over is an internal representation, or IR. This is what all the optimizers look at, rearrange, throw out, add to, spin, fold, and mutilate.
(Up to 4.0, there was really only one thing in GCC that could be properly called an IR. Now, like most other nontrivial compilers, there's more than one. It doesn't change the political situation; any of them could play the part of "the IR" here.)
Once the optimizers are done transforming your impeccable code into something unrecognizable, the chip-specific backends change the IR into assembly code. (Or whatever they've been designed to produce.)
Each of these transformations throws away information. What started out as a smart array class with bounds checking becomes a simple user-defined aggregate, which becomes a series of sequential memory references, which eventually all get turned into PEEK and POKE operations. (Rename for your processor as appropriate, or look up that old joke about syntactic sugar.)
Now -- leaving out all the details -- it would be Really Really Useful if we could look at the PEEKs and POKEs of more than one.o at a time. Since the compiler only sees one.c/.cpp/.whatever at a time, it can only optimize one.o at a time. Unfortunately, typically the only program that sees The Big Picture is the linker, when it pulls together all the.o's. Some linkers can do some basic optimization, most of them are pretty stupid, but all of them are limited by the amount of information present in the.o files... which is nothing more than PEEK and POKE.
As you can imagine, trying to examine a pattern of PEEK and POKE and working out "oh, this started off as a smart array class with bounds checking, let's see how it's used across the entire program" is essentially impossible.
Okay, end of backstory.
The solution to all this is to not throw out all that useful abstract information. Instead of, or in addition to, writing out assembly code or machine code, we write out the IR instead. (Either to specialized ".ir" files, or maybe some kind of accumulating database, etc, etc; the SGI compiler actually writes out.o files containing its IR instead of machine code, so that the whole process is transparent to the user.) Later on, when the linker runs, it can see the IR of the entire program and do the same optimizations that the compiler did / would have done, but on a larger scale.
This is more or less what all whole-program optimizers do, including LLVM. (I think LLVM has the linker actually calling back into the compiler.)
The "problem" is that between the compiler running and the linker running, the IR is just sitting on the disk. Other tools could do whatever they want with it. RMS's fear is that a company would write a proprietary non-GPL tool to do all kinds of neat stuff to the IR before the linker sees it again. Since no GPL'ed compiler/linker pieces are involved, the proprietary tool never has to be given to the community. Company wins, community loses.
End of problem description. Begin personal opinionating.
It's a legitimate concern, but many of us feel that a) it's going to happen eventually, and b) we do all GCC users a disservice by crippling the tools merely to postpone an inevitable scenario. As usual, there's a wide range of opinions among the maintainers, but the general consensus is that keeping things the way they are is an untenable position.
Re:Major Features Dropped From GCC 4.0
on
GCC 4.0 Preview
·
· Score: 4, Informative
Yeah, heavy on the "might".
Politics is what's preventing us from considering LLVM, let alone the long and torturous process of making the code work. The brutally short story is that GCC is operating under a certain restriction imposed by RMS since its inception, and LLVM -- or really, any good whole-program optimization technique -- would require us to violate that restriction.
Now, there are some of us (*waves hand*) who feel that RMS is a reactionary zealot in this respect, and would be more than happy to use the LLVM techniques, but we won't get into that.
The compiler server branch is still being worked on, so it won't be in 4.0, but might be in 4.1 or 4.2 or... It's only a few people working on it, after all.
Re:Screenshots!
on
GCC 4.0 Preview
·
· Score: 4, Informative
Point-by-point response:
From "make --help" comes the answer:
-s, --silent, --quiet Don't echo commands.
All that information is available, but only if you let make echo the commands.:-) The directory is printed as make changes directories, the command is printed as it's run, etc, etc. You might try something like "make foo > make.log", which will still print stderr to the screen.
Okay, well, you need to decide what you want to see. Some projects "echo gcc -f... -I... > Compile", and then the makefile rules and make output is just "./Compile foo.c" on each line.
That's tricky to do. Which tool's responsibility is it?
The gcc/g++ driver's purpose in life is to rip through the command line, figure out what other programs need to be run (compiler, assembler, linker, etc), fork them all off -- possibly in a loop, if you've passed more than one file on the command line -- and clean up afterwards.
"gcc -> real-work-programs" or "g++ -> real-work-programs" is a much faster executation path than "sh parser -> gcc -> real-work-programs", especially when your makefile is repeatedly invoking g++.
Maintainence is not especially difficult; g++ isn't really a seperate program. The difference between gcc and g++ is one or two extra.o files that get linked into the final executable. (Same for other language drivers that can't get by with plain "gcc", like the Java one.)
Re:Gentoo system rebuild!
on
GCC 4.0 Preview
·
· Score: 4, Funny
We now actually detect when GCC is running on a Gentoo system, and will occasionally miscompile an inner loop, just to make you twitch. The biggest complaint we received from Gentoo users during the 3.x series was that GCC was too boring, so we threw this in to keep you on your toes.
Pretty much every compiler in serious production use uses SSA internally.
This is a troll, right?
on
GCC 4.0 Preview
·
· Score: 5, Interesting
The gcc team seem to have no respect for legacy code.
You've got to be fucking kidding me.
Have a look at the mailing list anytime somebody reports a bug, and the choice is between fixing the bug and changing the ABI. Watch the flamefests erupt.
(Watch them die down a few days later as one of the brilliant core maintainers manages to do both, with a command-line option to toggle between the default fixed version and the buggy old version.)
Wait a few months. See a new corner-case weird bug some in. Lather, rinse, repeat.
Incompatible syntax changes
Such as...?
All the ones I can think of were GCC extensions long before they were officially added to the languages. In fact, their presence in GCC actually influences their presence in an official language standard, because that's what the standards bodies do: standardize existing practice.
The troublesome part is when the syntax as added to the language standard differs from the extension that was originally put in GCC. Then we have to choose which once to support -- because supporting both is often not feasible -- knowing that whatever choice we make, slashdot is going to whinge about it.:-)
I realize that things have to change, but I wish that they would not break compat between versions quite so often...
Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)
We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.
I'd really like to be able to take a binary between versions, and it just work.
Wanna know when this is gonna happen? Sooner, if you help.
"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!)
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.
Some of us will never be able to afford a down payment on the insurance for the down payment on a house. (Whatever that three-letter insurance acronym is.) Some of us will be renting until we die.
'Cause, as we all know, Slashdot was the only news-reposting site to cover this story, so if Google noticed any criticisms at all, it had to come from here. A site such as, say, searchenginewatch.com, would never have mentioned it.
The articles linked only say that this patient received three transplants. Nothing more.
Where is your source for the conclusion that every patient is going to need three transplants?
For all these brief articles tell us, maybe one procedure would be sufficient for a diabetic in better condition; Mr Lane sounded in pretty bad shape (falling into comas on a semi-regular basis) to this here diabetic.
For that matter, where do you get the "1 donated pancreas" == "1 islet cell transplant" equation? That's a mighty big leap to make given these scanty articles.
QMTest is an open-source testing framework that you should try. Fairly simple, adaptable, extensible. (Full disclosure: It's made by my company, but not by me. From reading the mailing lists, we get lots of kudos, so presumably it's working. *grin*)
As for other tools:
avoid Rational Rose like the plague of death. I used it for a year at a previous job, and had nothing but painful user-interface experiences and craptacular code to show for it.
CVS makes for a decent revision control system, but its limitations are a pain to work around. Subversion is considered mature, and Monotone is supposed to be quite nice, but I have no first-hand experience with them. Arch is suitable for small projects but does not scale (also, its author is an asshole, so you have no support there).
Unless you need to support some exotic environments, the autotools (autoconf/automake/libtool) have become more trouble than they're worth. Any of the mainstream make(1) implementations -- GNU Make, BSD Make, Solaris Make, etc -- will have enough extensions to let you do just about everything a build system needs to do. GNU Make is particularly rich, but use its features sparingly or your makefiles become undebuggable.
If you do need to support exotic environments, or think you might someday, then autoconf is your friend. Automake used to be friendly before they went overboard with it, now it's just bloated and broken; use Make extensions instead. Libtool has never been anybody's friend; more time has been put into making and debugging and debugging and debugging libtool than has ever been recouped by its wrappers -- use ELF binary format and be done with it.
Doxygen and Synopsis are both highly capable documentation tools.
bladesjester raises a good point. As an answer, I'll point to my own current job, where I and everyone else telecommutes. Including the boss.
This raises its own unique problems of visibility and communications. (We're comfortable with our solutions, which I won't yammer about here. But these problems did need to be addressed, and they won't go away on their own; if your company tries something like this, you will need to actively tackle them.)
If solved, though, telecommuting makes for a very nice visibility levelling field.
Well, this is linked to from the project front page, plus there's the MAINTAINERS file in the top of the source tree (although that lists the active maintainers and their responsibilities, not everybody-at-any-time-ever). Yah, Mark's one of them.
GCC isn't like the Linux kernel, where the development teams are formed around cults of personalities, and/.ers eagerly congregate to hear the heated flame wars between their favorites.:-) The GCC people are way milder, way less vitriolic, and as a result, don't make the tabloid news.
The inflammatory statements made on LKML concern stuff like DRM and proprietary drivers and things about which more Linux users actually care (or even understand). Inflammatory statements on the GCC list are of the kind which only arouse the ire of other compiler geeks. We can almost get into fistfights at the annual summit over whether a combined CSE and DCE pass should be done even when optimization is off ("the Laffer curve argues for-" "bah, users shouldn't notice!"), but nobody on/. will care. *grin*
That's what they told me when I was young; now I have a thin layer of really tough skin on either side of my fingers. Thin, but thick enough to prevent those tiny little lancets from penetrating enough.
The whole puncturing yourself to get at real actual blood thing is Not Good(tm).
Especially when we're supposed to make tiny pinpoint punctures on the fingers... which we use to type with. Ow ow ow ow ow with every keystroke. Screw that.
Slashdot Mirror
I've explained it in a sibling post just now. I was hoping to encourage people to go look up the discussions themselves, but if it's easier to accuse me of slander, so be it.
I didn't go into details because this has been covered elsewhere, and I'm tired of discussing it myself. But I didn't realize I would be accused of "uninformed slander". So. A bit of background info first.
Inside the guts of the compiler, after the parser is done working over the syntax (for whatever language), what's left over is an internal representation, or IR. This is what all the optimizers look at, rearrange, throw out, add to, spin, fold, and mutilate.
(Up to 4.0, there was really only one thing in GCC that could be properly called an IR. Now, like most other nontrivial compilers, there's more than one. It doesn't change the political situation; any of them could play the part of "the IR" here.)
Once the optimizers are done transforming your impeccable code into something unrecognizable, the chip-specific backends change the IR into assembly code. (Or whatever they've been designed to produce.)
Each of these transformations throws away information. What started out as a smart array class with bounds checking becomes a simple user-defined aggregate, which becomes a series of sequential memory references, which eventually all get turned into PEEK and POKE operations. (Rename for your processor as appropriate, or look up that old joke about syntactic sugar.)
Now -- leaving out all the details -- it would be Really Really Useful if we could look at the PEEKs and POKEs of more than one .o at a time. Since the compiler only sees one .c/.cpp/.whatever at a time, it can only optimize one .o at a time. Unfortunately, typically the only program that sees The Big Picture is the linker, when it pulls together all the .o's. Some linkers can do some basic optimization, most of them are pretty stupid, but all of them are limited by the amount of information present in the .o files... which is nothing more than PEEK and POKE.
As you can imagine, trying to examine a pattern of PEEK and POKE and working out "oh, this started off as a smart array class with bounds checking, let's see how it's used across the entire program" is essentially impossible.
Okay, end of backstory.
The solution to all this is to not throw out all that useful abstract information. Instead of, or in addition to, writing out assembly code or machine code, we write out the IR instead. (Either to specialized ".ir" files, or maybe some kind of accumulating database, etc, etc; the SGI compiler actually writes out .o files containing its IR instead of machine code, so that the whole process is transparent to the user.) Later on, when the linker runs, it can see the IR of the entire program and do the same optimizations that the compiler did / would have done, but on a larger scale.
This is more or less what all whole-program optimizers do, including LLVM. (I think LLVM has the linker actually calling back into the compiler.)
The "problem" is that between the compiler running and the linker running, the IR is just sitting on the disk. Other tools could do whatever they want with it. RMS's fear is that a company would write a proprietary non-GPL tool to do all kinds of neat stuff to the IR before the linker sees it again. Since no GPL'ed compiler/linker pieces are involved, the proprietary tool never has to be given to the community. Company wins, community loses.
End of problem description. Begin personal opinionating.
It's a legitimate concern, but many of us feel that a) it's going to happen eventually, and b) we do all GCC users a disservice by crippling the tools merely to postpone an inevitable scenario. As usual, there's a wide range of opinions among the maintainers, but the general consensus is that keeping things the way they are is an untenable position.
Yeah, heavy on the "might".
Politics is what's preventing us from considering LLVM, let alone the long and torturous process of making the code work. The brutally short story is that GCC is operating under a certain restriction imposed by RMS since its inception, and LLVM -- or really, any good whole-program optimization technique -- would require us to violate that restriction.
Now, there are some of us (*waves hand*) who feel that RMS is a reactionary zealot in this respect, and would be more than happy to use the LLVM techniques, but we won't get into that.
Point-by-point response:
That's a good URL, but the post is buried in 0-point-ness. Moderators, some love here, please?
Execution speed.
The gcc/g++ driver's purpose in life is to rip through the command line, figure out what other programs need to be run (compiler, assembler, linker, etc), fork them all off -- possibly in a loop, if you've passed more than one file on the command line -- and clean up afterwards.
"gcc -> real-work-programs" or "g++ -> real-work-programs" is a much faster executation path than "sh parser -> gcc -> real-work-programs", especially when your makefile is repeatedly invoking g++.
Maintainence is not especially difficult; g++ isn't really a seperate program. The difference between gcc and g++ is one or two extra .o files that get linked into the final executable. (Same for other language drivers that can't get by with plain "gcc", like the Java one.)
We now actually detect when GCC is running on a Gentoo system, and will occasionally miscompile an inner loop, just to make you twitch. The biggest complaint we received from Gentoo users during the 3.x series was that GCC was too boring, so we threw this in to keep you on your toes.
Cheers!
Pretty much every compiler in serious production use uses SSA internally.
You've got to be fucking kidding me.
Have a look at the mailing list anytime somebody reports a bug, and the choice is between fixing the bug and changing the ABI. Watch the flamefests erupt.
(Watch them die down a few days later as one of the brilliant core maintainers manages to do both, with a command-line option to toggle between the default fixed version and the buggy old version.)
Wait a few months. See a new corner-case weird bug some in. Lather, rinse, repeat.
Such as...?
All the ones I can think of were GCC extensions long before they were officially added to the languages. In fact, their presence in GCC actually influences their presence in an official language standard, because that's what the standards bodies do: standardize existing practice.
The troublesome part is when the syntax as added to the language standard differs from the extension that was originally put in GCC. Then we have to choose which once to support -- because supporting both is often not feasible -- knowing that whatever choice we make, slashdot is going to whinge about it. :-)
Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)
We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.
Wanna know when this is gonna happen? Sooner, if you help.
Even the most cursory search of the GCC mailing list archives would disprove this.
"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!)
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.
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.
Some of us will never be able to afford a down payment on the insurance for the down payment on a house. (Whatever that three-letter insurance acronym is.) Some of us will be renting until we die.
This may be the first time anybody has used a Tivo to record the commercials and skip the show.
'Cause, as we all know, Slashdot was the only news-reposting site to cover this story, so if Google noticed any criticisms at all, it had to come from here. A site such as, say, searchenginewatch.com, would never have mentioned it.
The articles linked only say that this patient received three transplants. Nothing more.
Where is your source for the conclusion that every patient is going to need three transplants?
For all these brief articles tell us, maybe one procedure would be sufficient for a diabetic in better condition; Mr Lane sounded in pretty bad shape (falling into comas on a semi-regular basis) to this here diabetic.
For that matter, where do you get the "1 donated pancreas" == "1 islet cell transplant" equation? That's a mighty big leap to make given these scanty articles.
QMTest is an open-source testing framework that you should try. Fairly simple, adaptable, extensible. (Full disclosure: It's made by my company, but not by me. From reading the mailing lists, we get lots of kudos, so presumably it's working. *grin*)
As for other tools:
bladesjester raises a good point. As an answer, I'll point to my own current job, where I and everyone else telecommutes. Including the boss.
This raises its own unique problems of visibility and communications. (We're comfortable with our solutions, which I won't yammer about here. But these problems did need to be addressed, and they won't go away on their own; if your company tries something like this, you will need to actively tackle them.) If solved, though, telecommuting makes for a very nice visibility levelling field.
It took me three paragraphs before I figured out that the author of the article wasn't talking about an operating system called "VR4".
Whitespace matters, people. "SystemV R4" or "SVR4" or "SysVR4" woulda done just fine...
Well, this is linked to from the project front page, plus there's the MAINTAINERS file in the top of the source tree (although that lists the active maintainers and their responsibilities, not everybody-at-any-time-ever). Yah, Mark's one of them.
GCC isn't like the Linux kernel, where the development teams are formed around cults of personalities, and /.ers eagerly congregate to hear the heated flame wars between their favorites. :-) The GCC people are way milder, way less vitriolic, and as a result, don't make the tabloid news.
The inflammatory statements made on LKML concern stuff like DRM and proprietary drivers and things about which more Linux users actually care (or even understand). Inflammatory statements on the GCC list are of the kind which only arouse the ire of other compiler geeks. We can almost get into fistfights at the annual summit over whether a combined CSE and DCE pass should be done even when optimization is off ("the Laffer curve argues for-" "bah, users shouldn't notice!"), but nobody on /. will care. *grin*
That's what they told me when I was young; now I have a thin layer of really tough skin on either side of my fingers. Thin, but thick enough to prevent those tiny little lancets from penetrating enough.
Especially when we're supposed to make tiny pinpoint punctures on the fingers... which we use to type with. Ow ow ow ow ow with every keystroke. Screw that.