Interview with Mark Mitchel, GCC's Release Engineer

ICC-Rocks writes "In light of the imminent release of the first 'stable' version of GCC version 3, OSNews features an interview with Mark Mitchel, GCC's Release Engineer. They are talking about GCC 3.x, the future and the competition."

Comments

Summary

[cjpez]

Question: Blah blah blah irrelevant blah.
Answer: Blah blah blah I don't know blah.

Brilliant, really.

Re:Summary

[Anonymous Coward]

You forgot to say "FIRST POST", clown.

Maybe RedHat should start releaseing the real ver!

[Anonymous Coward]

Yes, even RedHat 7.3 still has the piece of crap 2.96 compiler. WE as a community stand up and say to dist people. USE RELEASES PLEASE.

RedHat, please, just make it easier to play with the system and include the stuff that we all will go and download 20 seconds after install. Please. This compiling compilers like 2.95.3 and 3.0.4 is a waste of my time.

Note: About my insinuations about GCC 2.96 brokenness, I work side by side with a person who used to be on the GCC/GNU team, and has found strange bugs in certain version of the glibc that has been compiled by the 2.96 series. It went away when using release glibc compiled by release GCC. I personally have seen evidence that this is not FUD concerning GCC 2.96 - so please, all the flaming Bero zealots explain why is it now better to have a kluged compiler when the GCC team has far superceded it?

Good - they use glibc 2.2.5 - a standard GNU release, but they compiled it with the LAME 2.96 compiler. We shall SEE if they got the compiler It has been said that if a broken compiler compiles a library the library can be strangely broken and very difficult to debug. This goes to show RedHat why they shouldn't do this, and properly couple GLIBC 2.2.5 with GCC 3.0.4 as intended by GNU. Bero seems adamant about maintaining a 2.96 fork, which is costing time and resources and annoying users. I wouldn't care so much if 1.1.2, 2.95.3, 3.04 and RH-BROKEN.296-special were all included, but such is not the case. Lame.

However, why did gcc3 appear in 7.2 and not 7.3? All I ask is that yes, they can compile how they see fit, and so can I. My only request is to for them to provide the rest of the compilers for me that have been cleanly installed "their way," so that I don't have to go through the same shenanigan every time I upgrade or change a system or install a new one, etc.

On a side note, as far as GCC 3.X not being prime time, for C is surely is, I don't know about the rest, but for C its, as far as I can see, quite useable, stable and reliable with some interesting new optimizations. I also like ICC, from Intel, but they have very strange and frustrating licensing weirdness, and the kernel can't be compiled with it.

A lot of the GCC 3 is broke with regards to the C++, that's a crock. Both sides blame the other, but from what I have seen, most of the crap that doesn't compile right on GCC 3.x is the writer's fault, not the compiler. Think, what is harder, writing hello world or writing a compiler to compile hello world. I'm more inclined to believe the compiler guy that has to work on the project.

I see the reason to maintain binary compatibility to a point. For their manageability it makes sense, to some degree. So if its easier for them to put stuff out, go ahead.

I think that GNU has been a great force in the world, and to uselessly outpace them or point fingers at them is frustrating and bad for both sides of the camp.

One more note on RedHat, I am what would be the "customer," I do buy the media and get RH with new systems, etc. "Customers" who use this as a server don't like things being out of whack. I wish I could make it a requirement that the EGCS 1.1.2 release, 2.95.3 release, GCC 3.0.X release be included already to make things easier. It was there in 7.2, and then yanked out. I didn't hear the pissing and whining from the usual suspects about why this was done, but, I can only imagine they went off in some strange direction and have to dig themselves out quietly and slowly form this bastard fork, which, NO "readme," or "install" doc *EVER, EVER* requests. Face it. 2.96 is some RedHat only (Not Mandrake, Not SuSE) strange kluge. Programmers ignore in favor of GNU releases. Debian ignores it. It's a strange wart that needs wart removing acid, now. ;p

short intro

[tps12]

Background for newbies...

GCC is the compiler du jour for minority hobby operating systems like Linux and BSD. It was invented as part of the GNU project as a replacement for proprietary tools such as Visual C[++] on Windows, and has done a fair job at keeping up.

A while back, there was a small uproar over the egcs compiler, a competing product, but when Linux bought out Egcs.com, for better or for worse, the two became one. Since then allegations have flown regarding the stability and security of GCC.

It looks like things are finally back on track for GCC, and I think we have everyone to thank.

Re:short intro

[Zapman]

I'm not sure that I'd spin the story like that, especailly about the "linux buying out egcs.com".

Gcc seamed like it had been stagnant forever at the 2.7.* branch. If you look at the release history, you'll see that 2.7 was first released in June 95, and 2.7.2.3 was released in August of 97. Two years of point releases, with nothing new.

Well, some folks got tired of it, and forked the code. They made something called pgcc, which had more optimizations for the pentium (I) arch. Some of you may remember that the main distinction between redhat and the origional mandrake release was that Mandrake compiled all of redhat's packages with pgcc (except the kernel)

One thing led to another, and the pgcc fork got folded into the egcs versions. People were dismayed that there were 2 competing versions of gcc lying around but only one of them seemed to be moving: the egcs one. Egcs released version 1.*

Finally, the egcs and the gcc folks got to talking, and the egcs board became the gcc steering committee. If you look at the gcc release history, you'll see the egcs versions listed there too, because egcs became gcc 2.95.*

The gcc release history can be found at: http://gcc.gnu.org/releases.html

Re:short intro

[Anonymous Coward]

Thanks for the info. GNU rules, and I am against the RedHat 2.96 hack as well.

One quick tip, not meant to be rude;

Things SEEM (look,appear), not seam (a line junction). Seam is a junction between two boundaries.

Seem is to appear, to look.

seem
v 1: give a certain impression or have a certain outward aspect;
"She seems to be sleeping"; "This appears to be a very
difficult problem"; "This project looks fishy"; "They
appeared like people who had not eaten or slept for a
long time" [syn: look, appear]
2: seem to be true, probable, or apparent; "It seems that he is
very gifted"; "It appears that the weather in California
is very bad" [syn: appear]
3: appear to exist; "There seems no reason to go ahead with the
project now"
4: appear to one's own mind or opinion; "I seem to be
misunderstood by everyone"; "I can't seem to learn these
Chinese characters"

And..

seam
n 1: joint consisting of a line formed by joining two pieces
2: a slight depression in the smoothness of a surface; "his
face has many lines"; "ironing gets rid of most wrinkles"
[syn: wrinkle, furrow, crease, crinkle, line]
3: a stratum of ore or coal thick enough to be mined with
profit; "he worked in the coal beds" [syn: bed]
v 1: put together with a seam; "seam a dress"
2: join with a seam

This is a public service announcement, as it is a horribly abused word, and is not meant to be rude.

The only rudeness I want to convey is to BERO, for being a zealot and a nepotist.

GCC 3.0 has some great features

[PhysicsGenius]

With 3.0 gcc is finally poised to be the compiler of choice for all operating systems. Consider this feature set:

-Just In Time assembling (JITa)
-pipeline overflow caching
-memory protection beyond the 4 MB barrier
-interlaced object replacement with error redundancy cycles
-and much, much more

It's a great time to jump in and learn to program which is just what I intend to do.

Re:GCC 3.0 has some great features

[Permission Denied]

This is hilarious - did anyone else catch this?

This guy got a +1 Informative for this:

-Just In Time assembling (JITa)
-pipeline overflow caching
-memory protection beyond the 4 MB barrier
-interlaced object replacement with error redundancy cycles

He just made that all up. Memory protection beyond the "4 MB barrier?!" Lol. This is classic, really.

GCC white tower.

[Zapman]

8. What did you think about the Intel Compiler v6 that came out recently? Did you have time to have a look at it?

Mark Mitchel: I do not have enough information about that compiler to comment on it.

I know that x86 is just 1 arch for gcc, however it is an important one, being the most common. I would think that those heavily involved with gcc (and especially the x86 backend) would be much more interested in how well the other compilers performed since they are 'the competition' as it were.

It's kind of depressing that he 'doesn't have enough information to comment'.

if intel's compiler had been released last month or thereabouts, I could understand, but IIRC, it was released about 6 months ago.

Re:GCC white tower.

[4of12]

I know that x86 is just 1 arch for gcc, however it is an important one,

Yes, indeed.

Not knowing the first thing about compilers or the details of how gcc looks on the back end, I'm curious:

Does the instruction set agnostic nature of gcc severely impede how optimizing the compiler can be?

Not to complain too much, though. I've always been impressed that gcc runs on such an incredibly broad range of platforms. I've used for over 10 years and would frequently build it on new machines either where the compiler was not bundled and licensed for general use, or where the vendor supplied compiler was unable to compile my code.

Re:GCC white tower.

[Zeio]

I have used that compiler, ICC, it is impressive. I would recommend it to anyone. It increases speed by at least 15%, and this happens to Athlon as well. It is the best x86 compiler out there bar none - in terms of performance and x86.

Keep in mind this compiler has strange licensing, weird runtime restrictions that curiously favor the use of IA-64. A way around the linked restrictions in licensing is to build statically.

It would be nice if Intel gave the GCC team the secret sauce which makes this one some much better at optimizing code. I do not flame GCC at all, I like it , and clearly it is superior at going across architectural boundaries. I just wish HP/DEC/Compaq, Sun and Intel were more willing to show them a 'thing or two' about insightful ways to optimize the compiler.

Also, note that ICC can not compile the kernel. I know and have been told that there are things present in GCC that allow the successful build of the kernel that do no (CAN NOT?) exist in ICC. It would interesting to see if someone could get the kernel to build with ICC by hacking a mixture of the two compilers.

Another strange thing about ICC is that they are not entire GNU aware, and have an odd licensing file and install procedure. We had some problems with linking that were an obvious kluge and required a workaround. It would be nice to see the source for this, but that will not happen in the near future.

Best of luck to both teams, and I suggest that Intel, if you want the world to love x86 (even more), drive the stake in, and show us the source so that we can make GCC considerably better on x86.

I recommend that people try ICC whenever possible and take measurements.

I appreciate his honesty in not commenting on it, but seriously, this guy is way too smart to ignore what else is going on in compiler-land, and if he isn't measuring himself to the "competition," then he has stuck his head in the sand. I recommend that where ever possible he builds with the respective compilers every piece of code and looks for comparative anomalies and or performance differentials in order to learn from that.

Best of luck to the GNU GCC team!

Re:GCC white tower.

[V. Mole]

The goal of GCC is to work on a wide variety of architectures, which it does.Another goal is to comply with various language standards, which is getting there. Performance is a much lower priority -- it's "good enough" for most uses, and if you seriously need to crunch some numbers, well, then you need to spring for the vendor's compiler. My experience (several years working on software that ran on SunOS/Solaris, AIX, HP-UX, and (Open)VMS) was that GCC was a superior tool for developement and debugging (much better compliance and error messages), but then we went with the vendor compilers for final testing and release to get the performance we needed.

GCC is *not* competing with ICC, because they have different goals and different target markets. As far as Mr. Mitchel evaluating ICC, he probably can't due to fears of copyright or patent infringement.

Re:GCC white tower.

[Anonymous Coward]

That's a cop out, and you know it.

Sticking your head in the sand isn't a way to garner support for you effort. I love GNU GCC and what they have done, but they have a lot to learn about optimizations on various platforms.

You can check the performance differentials on two a.out and compare.

And, yes, if ICC compiled the kernel, I would simply use that. So they do compete.

Meowmix.

Re:GCC white tower.

[leastsquares]

Yes the x86 platform is very important, and therefore I would have expected a competent compiler developer to at least take a look at the free (as in beer) Intel compiler.

Mitchel comments that the speed of _your_ code it the only important benchmark. This is very true. Well, my code runs, on average, 2.1 times faster on my PC when compiled with the Intel compiler. This speed increase is just too large to ignore.

A friends application runs more than 3x faster after compilation with icc. -- And that is after spending considerable effort determining the optimal optimisation parameters for gcc, and then just using "-O2 -tpp6" with icc!!!

I like gcc... but it is currently losing the race.

Re:GCC white tower.

[norwoodites]

Everyone should read the front page of http://gcc.gnu.org and will see that the DFA branch has been merged into the mainline (aka the future gcc 3.2). A couple of people are working on the DFA based processor descriptions for the x86: Athlon and Pentium I,II,III, and IV, and also 486.

Re:GCC white tower.

[Micah]

> As far as Mr. Mitchel evaluating ICC, he probably can't due to fears of copyright or patent infringement.

That seems pretty unlikely. For patents, if gcc were to step on an icc patent, it would do so whether or not he used ICC.

For copyrights, I don't think he'd even potentially be liable unless he saw the ICC source code. And Intel keeps the source secret, right?

IANAL of course.

Re:GCC white tower.

[leastsquares]

Yes but the Intel compiler is here NOW. And, my code is shipping NOW.

When will a stable gcc 3.2 be available? I expect the Intel compiler will have been improved again by then. Compare icc 5 with icc 6.

Re:GCC white tower.

[yellowstone]

Does the instruction set agnostic nature of gcc severely impede how optimizing the compiler can be?

It turns out that compiler optimizations divide nicely into two categories:

1. Optimizations on the Intermediate Representation (i.e. not specific to any platform)

2. Optimizations on the generated (CPU sepcific) code

So the only drawback is that optimizations for a specific CPU may or may not be appropriate for other CPUs. However, even at the CPU-specific level, there's a lot of stuff (e.g. register allocation, instruction scheduling) that could use the same code base, just using CPU-specific callbacks as needed (i.e. use the Framework Pattern).

Re:GCC white tower.

[dvdeug]

I like gcc... but it is currently losing the race.

Any given compiler will lose some races. If the rules of your race call for the most optimizing compiler for the ix86, then GCC loses. If your race calls for a compiler that's portable to the various Linux, Windows and BSD platforms and that your users can get easily (i.e. comes with their OS, preferably), or they call for an Objective C, Java, Fortran or Ada compiler, then GCC leaves icc in the dust.

Re:GCC white tower.

[leastsquares]

I agree with what you say, but would like to add a few comments:

- If speed is an issue, then you'd nearly always choose the native compiler. (Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.) gcc couldn't be expected to compete, speed-wise, on a huge range of systems.

- In the case where you ship code, you shouldn't rely on the end-user having a particular compiler. I really, really wish that every system did have gcc though.

- If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

Re:GCC white tower.

[dvdeug]

If speed is an issue, then you'd nearly always choose the native compiler.

This isn't automatically true. When GCC was first ported to the Sun, it beat the native compiler by, IIRC, 30%. While I have no recent numbers, it wouldn't surprise me if this were still true in some cases; GCC has a lot of optimization work done on it, and the hardware vendor may not have the ability to produce a highly optimizing stable compiler. The ix86, a CISC chip that brings in loads of cash for its maker, is of course an exception.

Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.

The set of strictly conforming C or C++ programs isn't very large, and the set of C or C++ compilers guarenteed to work correctly is empty. How much work one should take to work around the bugs and hideous malfeatures of many compilers instead of dealing with the bugs and hideous malfeatures of just one compiler is up to the programmer; many programs aren't worth the trouble to get them running for the people who insist on compiling them with WeirdC (we've been working towards ANSI C for almost twenty years now!).

If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.

If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

Re:GCC white tower.

[leastsquares]

If speed is an issue, then you'd nearly always choose the native compiler.

This isn't automatically true.
What? You don't think that it isn't automatically true that you would nearly always choose the native compiler?

OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.

So I assume that you've tried debugging multi-threaded C/C++ code with gdb then? Java isn't an option for typical CPU intensive code. I'd love to use Ada, except I'm not about to migrate half a million lines of code.

This is something you might want to consider

[Anonymous Coward]

gcc 2.96 is actually more standards compliant than any other version
of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable yet).
It may not be "standards compliant" as in "what most others
are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98
compliant, unlike any previous version of gcc.

gcc 2.96 has more complete support for C++. Older versions of gcc could
handle only a very limited subset of C++.

Earlier versions of g++ often had problems with templates and other
valid C++ constructs.

Most of gcc 2.96's perceived "bugs" are actually broken code
that older gccs accepted because they were not standards compliant - or, using
an alternative term to express the same thing, buggy.
A C or C++ compiler that doesn't speak the standardized C language is
a bug, not a feature.
In the initial version of gcc 2.96, there were a couple of other bugs.
All known ones have been fixed in the version from updates - and the version
that is in the current beta version of Red Hat Linux. The bugs in the initial
version don't make the whole compiler broken, though. There has never been
a 100% bug free compiler, or any other 100% bug free non-trivial program.
The current version can be taken from Red Hat Linux 7.2. It will work
without changes on prior 7.x releases of Red Hat Linux.
Since a lot of people claim 2.96 is buggy because of the accusations
found in MPlayer documentation, I have
included the facts that led them to incorrectly believe that 2.96 is buggy
here.

gcc 2.96 generates better, more optimized code.

gcc 2.96 supports all architectures Red Hat is currently supporting,
including ia64. No other compiler can do this. Having to maintain different
compilers for every different architecture is a development (find a bug, then
fix it 4 times), QA and support nightmare.

The binary incompatibility issues are not as bad as some people and
companies make you believe.
First of all, they affect dynamically linked C++ code only.
If you don't use C++, you aren't affected. If you use C++ and link statically,
you aren't affected.
If you don't mind depending on a current glibc, you might also want to
link statically to c++ libraries while linking dynamically to glibc and other
C libraries you're using:
g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
(Thanks to Pavel Roskin for pointing this
out)
Second, the same issues appear with every major release of gcc
so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.

Besides, it can easily be circumvented. Either link statically, or
simply distribute libstdc++ with your program and install it if necessary.
Since it has a different soname, it can coexist with other libstdc++ versions
without causing any problems.
Red Hat Linux 7 also happens to be the first Linux distributions using
the current version of glibc, 2.2.x. This update is not binary compatible with
older distributions either (unless you update glibc - there's nothing that
prevents you from updating libstdc++ at the same time), so complaining about
gcc's new C++ ABI breaking binary compatibility is pointless. If you want
to distribute something binary-only, link it statically and it will run
everywhere.
Someone has to be the first to take a step like this. If nobody dared
to make a change because nobody else is doing it, we'd all still be using
gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...

gcc 3.0, the current so-called "stable" release (released quite
some time after Red Hat released gcc 2.96-RH), fixes some problems, but
introduces many others - for example, gcc 3.0.1 can't compile KDE 2.2
correctly due to bugs in gcc 3.0.x's implementation in multiple inheritance
in C++.
Until another set of 3.0.x updates is released, I still claim 2.96 is
the best compiler yet.

Re:This is something you might want to consider

[Anonymous Coward]

Oh, yeah, Bero. When you guys are off fucking with C++, you broke the C compiler.

Yes I have proof.

No you cant see it because you are an elitist annoying asshole who doesnt listen anyway.

FO&D

Re:This is something you might want to consider

[Anonymous Coward]

AHEM. Explain GENTOO?

I think it might be Gentoo time.

As a reply to myself, I'd like to point out to all the Zealots who support the broken 2.96, why does GENTOO completely compile from SOURCE, and support all the major packages RH-7.3 does using, the OH GOD, 2.95.3 COMPILER?!?!?!!?!!!!! I can't believe the FUD that gets spread about this compiler war that doesnt exist, only in RedHat's mind.

Gentoo Linux 1.1a

Gentoo Linux 1.1a features Linux 2.4.18+ and a modern GNU development environment (glibc-2.2.5, gcc 2.95.3), XFS, ReiserFS, ext3, LVM, ALSA, pcmcia-cs support, "vanilla" (stock) kernel compatibility for those who prefer unpatched kernels, Xfree86 4.2, OpenGL, KDE 3.0 and GNOME 1.4/2.0, tcp-wrappers, xinetd, iptables and Linux QoS tools, modern qmail (with optional mysql and LDAP support), postfix and exim MTAs, GRUB boot loader (LILO is still available if you need it), 1500+ up-to-date ebuild scripts of your favorite apps, an innovative dependency-based startup script design, and of course Portage, a completely open design and a great developer and user community.

Sounds like RedHat minus the cruft and haphazard stuff. Funny how everything INCLUDING KDE 3.0 compiles.

Interesting. Gentoo said MODERN development environment, not BROKEN. I think ti sounds good.

Re:This is something you might want to consider

[SLOGEN]

yack yack yack.... All kinds of rant about why 2.96 is good

I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96. The libstdc++v3 from GCC 3.x is (almost) standard compliant.

Re:This is something you might want to consider

[jo42]

You wouldn't happen to be one of the wankers at RedHat that decided to ship this wee lump of doo, would you?

Re:This is something you might want to consider

[elflord]

I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96.

Then why won't any distributor use 3.0.x as its compiler ? Why have RH released 7.3 instead of moving to gcc 3.0? The answer is that gcc 3.0 have some fatal bugs which prevent it from compiling KDE correctly. Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly. Apparently, they've ramped up the C++ requirements for the 3.1 release, which means they're at least starting to take the issue seriously. However, this "ball dropping" exercise has kind of vindicated RH, who unlike the gcc project, need to ship a compiler that will compile the bulk of their distribution.

Re:This is something you might want to consider

[dvdeug]

Why have RH released 7.3 instead of moving to gcc 3.0?

Because RH 7.0 used 2.96 because they needed a new compiler (for various reasons) and 3.0 was going to be too far away. Instead of moving to 3.0 for 8.0 a month or two before 3.1 was put out (and having to use it throughout the 8.0 series), they waited for gcc 3.1.

In any case, with my experiance with Debian and GCC, whether they released 7.3 had little to do with when 8.0 came out came out. They had important changes for 7.2, and released them.

Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly.

It wasn't a good thing that they did that. However, gcc only has so many people working on it. I know, short of a huge last minute mistake, that my important code will work with GCC 3.1. There are Linux kernel developers who use kernels compiled on GCC 3.1. It should be worth it to someone in the KDE world to compile KDE on GCC snapshots and catch stuff that doesn't work.

Free content isn't supposed to mean content-free..

[Jerf]

I respect the guy for saying he doesn't know the answer rather then trying to make it up, but I don't see why the original website ran the story, let alone why it should be posted on Slashdot. The percentage of sentences with useful information seems to be in the low teens, and it's not like it's a terribly long article where that can be expected...

Re:This is something BERO BARF. Regugitate.

[Anonymous Coward]

Here we go.

Hi, BERO, or a BERO underling.

SHUT UP. SHUT UP.

I hate the FUD this loser produces. Someone *PLEASE* whoever this guy's boss is, wake up and get a clue, this guy is employing his friends to hack at GCC when it need not be done.

This is PURE regurgitated BULLSHIT. It's the same fucking playbook - every time.

Yet, I never read in an install book, ANYTHING ANYTHING asking for the RedHat compiler. In fact, 90% of the Install docs I read, say AVOID it.

GOOD fuckin JOB RedHat.

I like it, I use it, but it PISSES me OFF, especially when you don't provide release compilers to finish up customizing my system.

Re:Free content isn't supposed to mean content-fre

[clem.dickey]

The message is between the lines. If there were ever an interview with a developer working in "go away and don't bug me" mode, this is it.

Re:Free content isn't supposed to mean content-fre

[Permission Denied]

I respect the guy for saying he doesn't know the answer rather then trying to make it up

An essential difference between engineers and politicians or marketing droids. Refreshing, really.

Very thorough, indepth interview

[CounterZer0]

Is it me, or did he sound like compiler output?
"Not to my knowledge"
"No, It's not."

Never anything helpful ;)

Re:Very thorough, indepth interview

[Snowfox]

Is it me, or did he sound like compiler output?
"Not to my knowledge"
"No, It's not."

Never anything helpful ;)

To the contrary - if this had been an interview with a commercial product, he'd never have said no, he would have implied that they were working on or investigating every feature mentioned, and he'd have turned bad points into positive spin.

This was frank, refreshing and to the point. Short and factual is good.

Re:This is something BERO BARF. Regugitate.

[Anonymous Coward]

No, it's true, 2.95.3 is broken in a myriad of ways (wow, I have PROOF TOO). Some of us couldn't wait two years for a working 3.1 compiler, sorry.

Re:This is something BERO BARF. Regugitate.

[Anonymous Coward]

Breaking C to fix C++ is kind of silly, wouldn't you say? I know it's not perfect, but it's a release, people build to it as a point of reference, and its anomalies are clearly documents as much time has passed since its release. Your "RH" secret sauce approach with no one knows what the f**k you did approach is so much worse, and it is ANTI OSS philosophy. You just reduced the number of people reviewing the code in question probably by a order of magnitude, if not two.

Is that why the Linux 2.5 kernel doc says the following:

Linux kernel release 2.5.xx

These are the release notes for Linux version 2.5. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.

COMPILING the kernel:

- Make sure you have gcc 2.95.3 available. gcc 2.91.66 (egcs-1.1.2) may
also work but is not as safe, and *gcc 2.7.2.3 is no longer supported*.
Also remember to upgrade your binutils package (for as/ld/nm and company)
if necessary. For more information, refer to ./Documentation/Changes.

Please note that you can still run a.out user programs with this kernel.

I'm sure if Linux was more stringent, he would say:

"Don't use that fucking broken RedHat piece of shit fork. The C code it produces is crap and cannot be used"

Bero, crawl back into your hole. We want fucking release compilers in the dist. You can compile broken shit with your broken compiler all day long, but at least give us the RELEASE alternatives, maybe in usr/local, or something. PULEEZE.

Bero. You lose. Everyone I know complains of this. No one else's does this in their dists. Debian uses a CVS version of 2.95.3, and I don't see much on Debian than cannot be done on RH - in fact, there is nothing. YOU SPREAD LIES TO SUPPORT NEPOTISM. You have useless hires churning out broken fork code, and then you fuckin defend it.

Lame.

Re:This is something BERO BARF. Regugitate.

[Anonymous Coward]

Yet Debian Woody uses an unreleased GCC 2.95.4? There goes that argument.

Re:This is something BERO BARF. Regugitate.

[Anonymous Coward]

Funny - it compiles more thing that RH 2.96 does.

And its from GNU's CVS, not the RedHat toilet.

global optimization/inlining

[dfgdfgdfg]

4. What are your thoughts about moving the codegen after the linker, to allow for global optimization/inlining?

Compile all the program at once. Create one file that includes all source files and compile it in one step. Works fine and eliminates duplicate string constants.

Re:Maybe RedHat should start releaseing the real v

[Anonymous Coward]

Man, I'm starting to suspect that you DON'T LIKE REDHAT. Why don't you use something else?

MM is a C++ front-end guy.

[Per Abrahamsen]

MM is primarily a C++ front-end guy (when not being a release manager), and the interesting aspects of ICC is mostly in the i32 backend, so ICC is unlikely to be that interesting once MM has time.

I believe ICC use a version of the generic Edison C++ front-end (most good C++ compilers do), which MM is most likely already familiar with.

Can you blame him?

[devphil]

And since the 3.1 release is now nearly a month behind, due to no fault of Mitchell's, I'm not surprised that he's busy. :-)

Useless Interview

[pixel_bc]

Why was this posted? Totally devoid of any content.

Think of all the innocent electrons wasted!

Re:This is something BERO BARF. Regugitate.

[elflord]

That's only because a lot of software includes workarounds for broken gcc releases. It doesn't compile anything that uses the sstream header. It compiles a lot of nonstandard code. The 2.95 compiler has several severe problems with its standard library.

Re:This is something BERO BARF. Regugitate.

[elflord]

Breaking C to fix C++ is kind of silly, wouldn't you say? I know it's not perfect, but it's a release, people build to it as a point of reference, and its anomalies are clearly documents as much time has passed since its release. Your "RH" secret sauce approach with no one knows what the f**k you did approach is so much worse, and it is ANTI OSS philosophy.

Horseshit. Part of the "OSS philosoppy" is that the users have the right to revolt and fork a project when the maintainer drops the ball. gcc shipped a gcc 3.0 release that was (a) late, and (b) too broken to use as the base for a distribution. The fact that the gcc 3.0 series was not fit to be used for a distribution vindicates Redhats decision to fork, IMO. RH need a compiler that can build a number of software packages, and gcc didn't provide that.

Re:Maybe RedHat should start releaseing the real v

[elflord]

Note: About my insinuations about GCC 2.96 brokenness, I work side by side with a person who used to be on the GCC/GNU team, and has found strange bugs in certain version of the glibc that has been compiled by the 2.96 series. It went away when using release glibc compiled by release GCC.

gcc 2.96 contained bugs, but so did 2.95. Improving a compiler sometimes results in bugs that weren't there earlier ("regressions"), and we can see examples of this sort of thing in gcc 3.0. There are a number of improvements in gcc 2.96. As someone who writes C++ code, I've observed some important improvements in support for ISO/ANSI C++.

It has been said that if a broken compiler compiles a library the library can be strangely broken and very difficult to debug.

I've got news for you -- all this emotive rhetoric about "broken" gcc 2.96 isn't supported by facts. There are a number of things in gcc 2.95 that are also "broken", and on the balance of it, gcc 2.96 comes out as a somewhat stronger compiler.

On a side note, as far as GCC 3.X not being prime time, for C is surely is, I don't know about the rest, but for C its, as far as I can see, quite useable, stable and reliable with some interesting new optimizations.

Hmmmm... I've had some very wierd bugs pop up with the "interesting new optimisations". Seriously, gcc 3.0 is a tremendous improvement in a number of ways, but there are some fairly show-stopping bugs (including a substantial C++ ABI bug which means that it can't compile KDE correcty) Because of this bug, gcc 3.0 is unsuitable as a compiler for a Linux distribution, and this is why no distributor is going to ship it as the primary compiler.

I think that GNU has been a great force in the world, and to uselessly outpace them or point fingers at them is frustrating and bad for both sides of the camp

It's not "useless" outpacing. gcc 3.0 was late, and the 3.1 release that dealt with the stuff that needed fixing in gcc 3.0 was almost a year later. What Redhat did is released their own derivative version of the gcc 3 CVS that was customised for use as a distribution compiler. gcc 3.0 on the other hand is not useful as a distro compiler.

Programmers ignore in favor of GNU releases. Debian ignores it.

Programmers ignoring Redhat ? Laughable in the extreme. Programmers don't ignore it, but even if they did, it wouldn't matter, because anything that will copmile with gcc 3.0 and gcc 2.95 will compile with gcc 2.96. A number of distributors have included it.

Re:This is something BERO BARF. Regugitate.

[norwoodites]

But there was some talk about releasing a 2.95.4 release but that talk fized down now.