Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

egcs to become gcc

CmdrTaco posted more than 15 years ago | from the its-about-time dept.

GNU is Not Unix 127

An anonymous reader sent us this page (its in german! Use babelfish) which says that EGCS has been accepted as the official compiler of the GNU Project by RMS. I've seen a lot of confirmation of this, but nothing official on the GNU website. Anyway, I'm glad to see it. EGCS is a great compiler- it'll be even cooler once its simply GCC! Update: 04/21 01:26 by J : The GNU website has been updated. The EGCS steering committee has been renamed, and is now officially in charge of GCC.

Sorry! There are no comments related to the filter you selected.

Rejoice! (0)

Anonymous Coward | more than 15 years ago | (#1924983)

Great news that it's technically
good enough to be part of the
GNU project.

Here is the babelfish translation: (0)

Anonymous Coward | more than 15 years ago | (#1924984)

Yes, but did you notice that it got the possessive form of "it" correct?!?!?!

Its developers try to integrate different advancements of the GCC again into a product.

Incredible good news (0)

Anonymous Coward | more than 15 years ago | (#1924985)

As a C++ programmer I'm looking forward to actually use precompiled C++ libraries again since egcs and gcc has been incompatible for quite some time. And yes, use ANSI C++. Wohoo!

Finally no more gcc 2.7.2 (0)

Anonymous Coward | more than 15 years ago | (#1924986)

"the current kernel still seems to have problems with the egcs compiler
(or the other way around). one hopes that those buglets will be"

kernel 2.2.6-ac1 and egcs-1.1.2 play fine together.

Executive summary? (0)

Anonymous Coward | more than 15 years ago | (#1924987)

Not only less efficient, but incorrect. For example, functions by default return "int" in C, but "void" in C++.

That's the Yodafish translation (0)

Anonymous Coward | more than 15 years ago | (#1924988)

"in the future the official compiler of the GNU project will be."

Yoda patent infringement hate.
Tiny pieces of smudge Yoda make of you.

Mesa --. (0)

Anonymous Coward | more than 15 years ago | (#1924989)

The pgcc problem is with the -ffastmath stuff. edit the Makefile to remove the flag. I did, and Mesa worked faster compiled with pgcc without the fastmath flag than with egcs comiled with the fastmath flag.

On the other hand, I haven't managed to get the
pgcc-1.1.2 release to compile with egcs-1.1.2
. No idea why. It stops about half way through with an internal compiler error.

One other thing - I could compile 2.2.x kernel with pgcc, no problem, but the linux makefiles
insist on telling the comiler to compile
as a 486 or pentium in all instances. How do I convince it to compile with, for instance, -mamdk6 ???
(pgcc says it has a K6-2 optimising target.)

And another thing - the amd architecture is diverging from intel. Is there an "official"
name for a k6 linux - like i586-pc-linux-gnu
but amdk6-pc-linux-gnu ???
pgcc also says it uses -mamdk6 in the current release and -mk6 in the dev. snaphsots.
This goes for several releases back though ???
Which is it going to be ?

Can you program in AMD RISC86 stuff directly??
get rid of the x86 crud completely (I was once a
68k asm programmer- x86 asm is crap)











ANSI does not cover assembly (0)

Anonymous Coward | more than 15 years ago | (#1924990)

The kernel must use assembly. Linus and other
kernel developers used the documented syntax
that had supported ever since gcc 1.0.

Some idiot decided to change the syntax, and
then claimed that the gcc documentation was
wrong (they 'fixed' it to match the code) and
also claimed that Linux was buggy.

Linus called the bug a bug, and said he didn't
want to hack his kernel to support a compiler
that didn't meet its own specification.

No kidding, it was assembly! (0)

Anonymous Coward | more than 15 years ago | (#1924991)

Over the years, the compiler behavior changed
from something logical to something that only
a compiler developer could love.

Then they hacked the documentation to fit the
new behavior and said the kernel was buggy!

Yoda's German? (0)

Anonymous Coward | more than 15 years ago | (#1924992)

That all explains!

Yoda's German? (0)

Anonymous Coward | more than 15 years ago | (#1924993)

bahahaha
/me rolls over dead, still laughing.

RMS doesn't matter (0)

Anonymous Coward | more than 15 years ago | (#1924994)

It's been clear for the last year or two that
what RMS has to say really doesn't matter
to the open source movement. It existed before
him, and will exist after him. At times, it has
even existed despite him.

pgcc kills config.guess ;-) (0)

Anonymous Coward | more than 15 years ago | (#1924995)

I've run into this problem a bunch of times. Each time, though, I can't remember what I did to fix it... But I think it has to do with PGCC/EGCS not setting up a "cc" link to its gcc. IIRC, config.guess uses "cc" to compile and if you don't fix up the link, it'll end up using the old gcc but since some stuff's been replaced (again, I don't remeber what) it doesn't work properly... Give it a shot and let me know if it helps.

CPU name (0)

Anonymous Coward | more than 15 years ago | (#1924996)

-fi-0wn-you

Seriously, is this to tell it that you're using -O6 instread of -O2 ?
Even if it isn't, it'd be a cool thing to tell newasps...




Metalinguistic difficulties (0)

Anonymous Coward | more than 15 years ago | (#1924997)

Jesus.... I was reading this on a monochrome window and I thought you were suggesting that linking was a new feature of egcs 1.1. I's gon' have to open a can of WHIP-ASS on you, bwah....

Note to self: underline links, on.

Can anyone confirm this? (0)

Anonymous Coward | more than 15 years ago | (#1924998)

"Valid C programs can compile into something completely uninteneded when compiled by ay a C++ compliler" WTF? is that right?

why "canadian" ? (0)

Anonymous Coward | more than 15 years ago | (#1924999)

Did someone in Canada invent this method or something? Is it some ironic comment on Canadian politics?

you don't matter (0)

Anonymous Coward | more than 15 years ago | (#1925000)

go jump in a lake

Kernel +, Distro ++, Mesa --. (1)

Anonymous Coward | more than 15 years ago | (#1925007)

I didn't see too much of a difference when compiling my kernel with PGCC, but if you move to the Stampede distribution where *everything* is compiled to PGCC, you can see a much more revealing performance gain . . . the system becomes visibly "snappier".

OTOH: compiling Mesa 3d with pgcc leads to incorrect behavior. Haven't tried Mesa with EGCS.

Great! (1)

euroderf (47) | more than 15 years ago | (#1925008)

gcc and egcs rpm's can't seem to coexist without conflict, but now I have a good reason to choose egcs ...

Does this solve the glibc 2.1 problem? (1)

dwmw2 (82) | more than 15 years ago | (#1925009)

ISTR the problem with glibc 2.1 was that it wasn't compilable with the 'official compiler' of the GNU project.

I assume that this will expedite the (re)release of glibc 2.1? (Or has it been released already - I haven't bothered to check).

gcc & egcs co-existence (1)

stevied (169) | more than 15 years ago | (#1925012)

You can have multiple versions of gcc and / or egcs on your system, if you compile / install yourself. The actual "gcc" program you run is just a front end -- the actual compiler is usually in /usr/lib/gcc-lib///.

You select the version to run using the -V switch; so if you have egcs installed over gcc 2.7.2.3, gcc -V 2.7.2.3 will use the old compiler.

Works fine here.

gcc & egcs co-existence (1)

stevied (169) | more than 15 years ago | (#1925013)

That was supposed to be: /usr/lib/gcc-lib/<arch>/<gcc version>> But for some reason, even in "Plain old text" mode the <>s got eaten. Grr.

Here is the babelfish translation: (1)

Luis Casillas (276) | more than 15 years ago | (#1925014)

I once tried transalting some spanish into english with babelfish. The damn thing confused a very common noun for a very obscure verb I had never seen before (I am a native spanish speaker). It took me like two minutes of looking at the translation to figure out what the hell was happening, when I finally realized what it was. I looked up the word in question, and then I found out, for the first time in my life, that "tacar" in spanish is a verb, whose first person singular present for is "taco" (as in the mexican dish).

---

Executive summary? (1)

Bobort (289) | more than 15 years ago | (#1925015)

As to C/C++, no. Both gcc and egcs compile both C and C++. Using a C++ compiler for C would be possible, but I believe it would generate less efficient code.

does gcc support differing calling conventions? (1)

khaladan (445) | more than 15 years ago | (#1925016)

"GNU wouldn't exist without gcc."

Uh, GNU *MADE* GCC. GNU C Compiler.

"Think about what it would do to windows if everyone started getting windows freeware as source."

It would do nothing important if this happened. Go check out Cygwin. http://www.cygnus.com

3.0: roughly when? (1)

mce (509) | more than 15 years ago | (#1925017)

sometime in the near future there will be a gcc 3.0

What definition of `near future' is being used here? A few weeks? Something like a month or 2? More than 2 months still? Can anybody tell already?

I have glibc 2.1 and egcs 1.1.2 waiting to be installed over here, but need to find the time to do it. If the `near future' is sufficiently near, I might want to wait for it to come.

--

XEmacs (1)

Aaron M. Renn (539) | more than 15 years ago | (#1925018)

It's unfair to blame Stallman for this. There's plenty of venom on the xemacs side of the house as well.

GTKMacs (1)

toaster (567) | more than 15 years ago | (#1925019)

Emacs w/ GTK+ support would be soooo nice.

Installing both GCC and EGCS packages (1)

gavinhall (33) | more than 15 years ago | (#1925023)

Posted by Xenophon Fenderson, the Carbon:

I've done this on my Alpha at home (Red Hat Linux 5.2, kernel 2.2.3, glibc 2.0). As far as installation goes, be certain not to use the "-U" switch, and do use "-force" to cause it to over-write duplicates (e.g. /usr/bin/gcc).

Of course, you will also have to install the support packages, e.g. libstdc++.

The only thing of which you need to be careful is using the correct libraries with the correct compiler. For example, if you have both EGCS 1.0.3 and EGCS 1.1.2 installed, and you want to use EGCS 1.0.3 instead of the default 1.1.2, you'll need to tell the compiler to use the older library files (with -l and -nostdlibs or something like that).

I've got GCC 2.7.2.3, GCC 2.8.1, EGCS 1.0.3, and EGCS 1.1 on my Alpha. I used to use the older compilers to build kernels or programs that depended on certain compiler/library bugs. I haven't run into a show-stopper yet. If you have any problems setting this up, feel free to send me an email.


Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16

XEmacs (1)

Doug McNaught (668) | more than 15 years ago | (#1925024)

Okay, now all we're waiting for is GNU Emacs and XEmacs to merge ;)

I wouldn't hold my breath--rms seems to hate XEmacs and those involved with it with an unholy passion. I have a love-hate relationship with it myself (though I use it every day).

-Doug

XEmacs (1)

Doug McNaught (668) | more than 15 years ago | (#1925025)

Hmm, interesting interview. Hadn't seen that perspective on it before. Thanks.

-Doug

Executive summary? (2)

Doug McNaught (668) | more than 15 years ago | (#1925026)

Can anyone sum up the differences between egcs and gcc and explain why they haven't been combined up until now? I believe egcs is Enhanced GNU Compiler Suite and I think it's the C++ version of gcc. At least I usually see it mentioned in association with C++ programs although I've never used egcs.

They are basically the same system (backend compiler engine with frontends for C, C++, Objective-C, F77 etc). EGCS was started by taking the current version of GCC and forking it with a 'bazaar' rather than 'cathedral' model. As a result it's progressed a lot faster in both stability and features.

The reason you hear a lot about EGCS in relation to C++ is that it's a much better and more modern C++ compiler than GCC.

-Doug

XEmacs (1)

zerblat (785) | more than 15 years ago | (#1925028)

Okay, now all we're waiting for is GNU Emacs and XEmacs to merge ;)

Incredible good news (1)

demon (1039) | more than 15 years ago | (#1925030)

ANSI C++? Have you got a time machine that the rest of us haven't heard about? Because as far as I know, C++ still is not an ANSI standardized language.

egcs vs gcc (1)

Aki Laukkanen (1072) | more than 15 years ago | (#1925031)

You don't specify whether you compiled C or C++ programs. For latter the executables are naturally bigger since they are compiled with exceptions on. Try the -fno-exceptions compiler flag to see if there are any changes.

s/Human/German/; (1)

kip3f (1210) | more than 15 years ago | (#1925032)

geez claudius...
--
Man is most nearly himself when he achieves the seriousness of a child at play.

egcs vs gcc (1)

BadlandZ (1725) | more than 15 years ago | (#1925034)

About a month ago I was comparing the default gcc that shipped with Red Hat 5.2 to the newest version of egcs I could download from thier site.

Among the things I notices were that executable times/preformance for binaries created with these compilers were almost identical, BUT, the thing that suprized me most was that the binaries were about 15-25% larger when created with egcs.

Anyone else noticed this, or any other quirks about egcs?

Good news for Stampede GNU/Linux (1)

Outlyer (1767) | more than 15 years ago | (#1925035)

This is great news. I stopped using gcc some time ago (actually, about the same time kernel 2.2 and glibc2.1 were released) and everything compiled just beautifully, in fact the only problem I ever had was with kaffe.

Having the pentium-optimized compiler integrated into the default would help a lot as we wouldn't be stuck using slow-ass i386 binaries on our Pentiums/K6s.

Human Translation (2)

aprentic (1832) | more than 15 years ago | (#1925036)

Retirement in sight for gcc
The free GNU C/C++ compiler has a successor. The development of the replacement has been dragging along for quite some time now. The head of the GNU project Richard Stallman has now decided that, in the future, egcs shall be the official copiler of the GNU project.
The developers are trying to reintegrate the different improvements on gcc. Among these are the Fortran Frontend g77 and pgcc, which is optimized for the Pentium instruction set. More information at http://egcs.cygnus.com/

Thanks to the egcs people and the FSF (1)

Andy Tai (1884) | more than 15 years ago | (#1925037)

The EGCS people did a great job. We shall thank them for their contributions that make gcc potentially the best compiler available. Of course we shall thank RMS, the FSF, and all the past (mostly the same as current) gcc contributors as well who made gcc possible. It is good news that RMS accepts the suggestions of the egcs people and all work together in this important GNU project. It also shows GNU can support the bazaar way of development, contrary to ESR's connection of GNU to the cathedral.

Thanks to the GNU contributors for the GNU C/C++ compiler, the fundamental tool and the MOST IMPORTANT FREE SOFTWARE in the world.

CPU name (1)

mikpos (2397) | more than 15 years ago | (#1925038)

And another thing - the amd architecture is diverging from intel. Is there an "official"
name for a k6 linux - like i586-pc-linux-gnu but amdk6-pc-linux-gnu ???

Most likely not (yet). All AMD chips are fairly comparable to their Intel counterparts. The i586, i686, etc. CPU names still are 386-only instructions by default; there's really not much difference between them, so making another AMD branch would be pretty silly. I haven't paid too much attention to the K7, but it would seem that there would be enough differences in the architecture to warrant a new branch. I wonder if one would have to do some sort of Canadian Cross to compile a K7 (or IA64 for that matter) with an i386 gcc (assuming you're doing it from source).

As for your wanting -mamdk6 with the kernel, you could try forcing CFLAGS:
make CFLAGS="-mamdk6 -O6 -fomit-frame-pointers -fi-0wn-you" bzImage

If that doesn't work, you could always change all the Makefiles; can you run sed recursively? :)

Executive summary? (1)

mikpos (2397) | more than 15 years ago | (#1925039)

And having C++ automatically typedefing all the structs would lead to an endless amount of errors I think.

XEmacs (1)

mikpos (2397) | more than 15 years ago | (#1925040)

That's not entirely true. z00m over to here [umd.edu] and read the part where he talks about merging Emacs and XEmacs.

So can linux 2.2 compile with egcs now? (1)

slothbait (2922) | more than 15 years ago | (#1925041)

I was under the impression that kernel 2.0 was dependent upon a few quirks of the gcc compiler and would not properly compile under egcs. Is this not the case for kernel 2.2? As I saw it, this was one of the fundamental reasons for keeping gcc around, and if modern kernels are no longer tied to gcc, then all the better.

Looks like another long-awaited change that will (hopefully) make it into RH 6.0
--Lenny

//"You can't prove anything about a program written in C or FORTRAN.
It's really just Peek and Poke with some syntactic sugar."

RMS doesn't matter (1)

Andy (2990) | more than 15 years ago | (#1925042)

What a stupid comment. One of the benefits of free software is that someone can always come along and create a superior derived work. GPL guarantees that it remains free software. All of the ideas about the benefits of the free flow of information that Stallman espouses are proven true. Stallman is not deminished in the slightest if someone amends and improves his work.

Chill (1)

Ray Dassen (3291) | more than 15 years ago | (#1925043)

Quoting the announcement [cygnus.com] of the EGCS Chill frontend:
Chill is the "CCITT High-Level Language", where CCITT is the old name for what is now ITU, the International Telecommunications Union. It is is language in the Modula2 family, and targets many of the same applications as Ada (especially large embedded systems). Chill was never used much in the United States, but is still being used in Europe, Brazil, Korea, and other places.

Does this solve the glibc 2.1 problem? (1)

Ray Dassen (3291) | more than 15 years ago | (#1925044)

I assume that this will expedite the (re)release of glibc 2.1? (Or has it been released already - I haven't bothered to check).

This should solve the "political issue" indeed. glibc2.1 isn't on ftp.gnu.org yet, but then again, there hasn't been an official announcement from the FSF blessing EGCS as the one true gcc yet.

Good news (2)

Ray Dassen (3291) | more than 15 years ago | (#1925045)

This good news is also discussed on the EGCS list [cygnus.com]

As one of the co-maintainers of the Debian EGCS packages, I'm extremely happy about this. I've found the EGCS developers quite responsive about bug reports, and often found bugs in release versions to be fixed in snapshots already.

Executive summary? (4)

Ray Dassen (3291) | more than 15 years ago | (#1925046)

The primary difference is the development model. EGCS is bazaar [tuxedo.org] -style, whereas FSF gcc's was cathedral [tuxedo.org] -styl e.

What this meant in practice, was that EGCS advanced rapidly, and has succeeded in reintegrating most of the separate GCC development communities (C++, Ada, Fortran, Pascal, Pentium optimisations) with major improvements (Haifa scheduler, integrated testsuite, much closer to C++ standard).

Two cheers... (1)

thomasd (3336) | more than 15 years ago | (#1925047)

It's nice to see that there's going to be some kind of resolution for the `what compiler should I use' question. But I can't help feeling that it's just a little bit arrogant for the GNU project to come along and `accept' other people's work, when their own compiler project was obviously going nowhere fast. On this basis, of course it's possible to say that n% of code in a Linux distribution is GNU code. But shouldn't be the emphasis really be on getting some hacking done, not adding the GNU stamp of aproval to something we already know to be a good compiler supported by a healthy and active development team?

Here is the babelfish translation: (1)

Ken Broadfoot (3675) | more than 15 years ago | (#1925048)

Sure, I am not. Sprechen sie Yoda?

Eh, Bumbled for Babel Fish sure.

Here is the babelfish translation: (2)

Ken Broadfoot (3675) | more than 15 years ago | (#1925049)

English:


Separation for GCC in view The free GNU C/C++ compiler GCC got a successor. The development of the compiler/translator had sluggishly run already for some time. GNU boss Richard Stallman decided now that egcs in the future the official compiler of the GNU project will be. Its developers try to integrate different advancements of the GCC again into a product.

In addition among other things FORTRAN-FRONT-ENDS g77 belongs and particularly on Pentium operations optimized pgcc. closer information gives it with
http://egcs.cygnus.com /. (ck/iX)

Gravitational laws apply... (1)

hzo (3742) | more than 15 years ago | (#1925050)

While code forking is evidence that there exists
a centrifugal force in the world of open code,
code reunification is the living proof that there
must be an attractive force too.
BTW, what about anti matter, black holes, super novae? ;)

--

Cross support (1)

Bwah (3970) | more than 15 years ago | (#1925051)

egcs has FAR/ better cross platform support than gcc. It can target all sorts of interesting procs like coldfire and several ppc variants that gcc can't. It is also a lot easier to build as a cross or canadian cross.

/dev

Executive summary? (2)

Paul Carver (4555) | more than 15 years ago | (#1925052)

Can anyone sum up the differences between egcs and gcc and explain why they haven't been combined up until now? I believe egcs is Enhanced GNU Compiler Suite and I think it's the C++ version of gcc. At least I usually see it mentioned in association with C++ programs although I've never used egcs.

Does gcc do things that egcs doesn't, or is it just inertia that keeps people using gcc? In theory you don't need a C compiler, right? A C++ compiler ought to be able to compile all your C source code.

So can linux 2.2 compile with egcs now? (1)

Scola (4708) | more than 15 years ago | (#1925053)

Kernel 2.2 has always been compilable by egcs. In fact 2.1 was egcs ready since very early in its development. 2.0 had bug for bug compatability with gcc-2.7, which made it impossible to compile with any other compiler, or more acurately any compiler that propperly followed the ANSI C spec.

Finally no more gcc 2.7.2 (1)

kevin lyda (4803) | more than 15 years ago | (#1925054)

actually redhat install 2.7.2 by default so that you can recompile the kernel - alan cox has said for years that 2.0.x is to be compiled by gcc, not egcs.

the current kernel still seems to have problems with the egcs compiler (or the other way around). one hopes that those buglets will be squashed.

yes, it's true; egcs is gcc. Some details (1)

dvdeug (5033) | more than 15 years ago | (#1925055)

sometime in the near future there will be a gcc 3.0 from the egcs code base.

Why? Is there really any reason to jump the major version number, besides the clashing minors? (EGCS uses minors in the range of > 89, i.e. 2.91.?)

So can linux 2.2 compile with egcs now? (1)

LizardKing (5245) | more than 15 years ago | (#1925057)

I've been compiling my kernels with egcs and pgcc since the 2.1.* series. I haven't come across any problems, although officially the pgcc maintainer doesn't advocate the use of pgcc to compile Linux.

There is also some bad blood between the compiler and kernel crowd over who is resposible for the quirks that plague egcs/kernel 2.0.* builds.

I don't know enough about the egcs/pgcc code or compiler code to comment on who is right in all this, but I wish they'd work together on this.

Apparently Linus said some inflammatory remarks about possible bugs in the compiler code, while the compiler people maintain that it's down to bad kernel code.

Despite the official pgcc position (as espoused on the mainling list), I will continue to build my kernels with pgcc on Intel boxes and egcs on my Sparc.


Chris Wareham

Excellent news (2)

LizardKing (5245) | more than 15 years ago | (#1925059)

This is very encouraging - it goes against the common criticism of open-source software which states that such projects often fragment. Once the remaining features from PGCC are folded into egcs/gcc we'll have one superb compiler.


Chris Wareham

Excellent news (1)

arielb (5604) | more than 15 years ago | (#1925060)

I thought Intel was working with cygnus on more robust optimizations for gcc. PGCC was really just a proof of concept

good news for the timid (1)

Nemesys (6004) | more than 15 years ago | (#1925061)

Those who'll try any pre-alpha, non-standard software EXCEPT compilers, C libraries and kernels have the most cause to rejoice. The better system is now the official, approved one, and that matters a lot to the less hacky.

RMS matters (1)

JoeBuck (7947) | more than 15 years ago | (#1925065)

RMS is the original author and designer of gcc. The egcs steering committee thinks he matters very much, which is why we worked to satisfy his concerns. Certainly he's stubborn and doctrinaire, and at times is not the easiest person to get along with.

But even if you don't think all software should be free, there's a lot more free software in the world because of RMS's advocacy (and don't forget the considerable amount of software he wrote himself).

pgcc still separate (1)

JoeBuck (7947) | more than 15 years ago | (#1925066)

Ideally, the difference between pgcc and egcs/gcc will decrease over time, to the point where a separate pgcc branch is no longer needed. To a certain extent that's been happening.

yes, it's true; egcs is gcc. Some details (4)

JoeBuck (7947) | more than 15 years ago | (#1925069)

As a member of the egcs steering committee [cygnus.com] , which will become the gcc steering commitee, I can confirm that yes, the merger is official ... sometime in the near future there will be a gcc 3.0 from the egcs code base. The steering committee has been talking to RMS about doing this for months now; at times it's been contentious but now that we understand each other better, things are going much better.

The important thing to understand is that when we started egcs, this is what we were planning all along (well, OK, what some of us were planning). We wanted to change the way gcc worked, not just create a variant. That's why assignments always went to the FSF, why GNU coding style is rigorously followed.

Technically, egcs/gcc will run the same way as before. Since we are now fully GNU, we'll be making some minor changes to reflect that, but we've been doing them gradually in the past few months anyway so nothing that significant will change. Jeff Law remains the release manager; a number of other people have CVS write access; the steering committee handles the "political" and other nontechnical stuff and "hires" the release manager.

egcs/gcc is at this point considerably more bazaar-like than the Linux kernel in that many more people have the ability to get something into the official code (for Linux, only Linus can do that). Jeff Law decides what goes in the release, but he delegates major areas to other maintainers.

The reason for the delay in the announcement is that we were waiting for RMS to announce it (he sent a message to the gnu.*.announce lists), but someone cracked an important FSF machine and did an rm -rf / command. It was noticed and someone powered off the machine, but it appears that this machine hosted the GNU mailing lists, if I understand correctly, so there's nothing on gnu.announce. I don't know why there's still nothing on www.gnu.org (which was not cracked). Why do people do things like this?

does gcc support differing calling conventions? (1)

scrytch (9198) | more than 15 years ago | (#1925070)

I'm not really up on compiler design, but does gcc support an equivalent to the windows __stdcall and __cdecl declarations? Basically, can it generate windows code? GNU wouldn't exist without gcc. Think about what it would do to windows if everyone started getting windows freeware as source. Commercial unixen are being undermined by free unix because the free tools are portable and more functional. Microsoft believes in "embrace and extend", but we can counter it with "insinuate and absorb".

Here is the babelfish translation: (1)

orabidoo (9806) | more than 15 years ago | (#1925072)

no kidding! it makes me wonder if Babelfish does much actual parsing, or if it's just a glorified word-by-word translator with some rules to patch up the biggest syntactic differences. or don't the Babelfish guys know that English always puts non-single-word adjuncts *after* their heads?

C++ is not (a superset of) C (1)

orabidoo (9806) | more than 15 years ago | (#1925073)

wtf is Chill?

So can linux 2.2 compile with egcs now? (1)

Daa (9883) | more than 15 years ago | (#1925074)

egcs and linux 2 have a love hate relationship - linux uses a fair number of inline asms and pushs the limits of what is documented as legal asm's , egcs has been tightening the rules for asms because they were allowing code that ran out of registers. So egcs would start marking linux code as being illegal and then linus and the ecgs folks had to deal with how to fix the problem , sometimes the compiler was changed, sometimes the linux code got changed.

Pgcc has another problem in that many of the Pentium optimizations in pgcc are NOT crossplatform and need to be totally rewritten to be merged into egcs - some are done , but alot remain to be rewritten

egcs vs gcc (1)

Amit J. Patel (14049) | more than 15 years ago | (#1925075)

I too have noticed that programs are larger with egcs. However, it's not egcs's fault! It seems to be some quirk with egcs/gcc coexistence.

Try compiling your C code with -lstdc++ .. it made my executables shrink a LOT, even though the C++ library shouldn't really affect my C code.

- Amit

Executive summary? (1)

Amit J. Patel (14049) | more than 15 years ago | (#1925076)

As long as exception handling is turned off (-fno-exceptions), compiling C code with a C++ compiler should give you the same level of efficiency.

The problem is that C++ isn't a strict superset of C. There are some things you can do in C (but shouldn't in new code) that aren't legal C++.

CPU name (1)

VinceJH (14059) | more than 15 years ago | (#1925077)

Yea, change /usr/src/linux/arch/i386/Makefile, look down for your arch. K6 is under the "CONFIG_M586TSC:" label

Executive summary? (1)

Maciej Stachowiak (14282) | more than 15 years ago | (#1925079)

The code would not necessarily be less efficient. However, a C++ compiler cannot successfully compile all valid C programs.

pgcc kills config.guess ;-) (1)

gibson (14565) | more than 15 years ago | (#1925080)

I've installed pgcc-1.1.1 to replace gcc/egcs (RedHat-5.2), using the RPMs linked to from the PGCC website [ml.org] and compiled my kernel with -mpentium -DCPU=i586 or the likes.

Since then, config.guess of each and every source package using configure bails out. "Can't determine host type" or the likes.

I've been adding "--host=`uname -m`-`uname -s | tr [A-Z] [a-Z]`" to my *.spec files, but that's stupid. Any suggestions?

Or not (1)

dosowski (15924) | more than 15 years ago | (#1925083)

I believe "Human Translation" meant translated by a human, and not by babelfish. :-)

pgcc still separate (4)

crow (16139) | more than 15 years ago | (#1925084)

I've seen several people seem to be confused here thinking that the merger of egcs and gcc means having a Pentium-optimized gcc as the standard C compiler. This is not the case. As of yesterday, there were a number of compilers out there:

gcc-2.7.2.x: Required for Linux 2.0.x kernel builds due to bugs in the kernel code, and possibly more stable for some 2.2.x kernels, though it is less clear whether that is due to the kernel or the other compilers. Though it includes various front ends, generally it is only used for C anymore.

gcc-2.8.x: A major upgrade to gcc; the "standard" gcc. Like always, includes C, C++, and other front ends.

egcs-1.1.2: The actively-developed gcc spinoff. This is generally regarded as being superior for C++ and every bit as good for C as gcc-2.8. For most people, this is a total replacement for gcc-2.8.

pgcc-1.1.x: This is an egcs spinoff, with active development on various compiler optimizations, particularly emphasising Pentium-specific improvements. Because optimization is about as deep into the arcane black arts of compilers as you can get, it is not surprising that pgcc is believed to be less stable than egcs. However, some of the more solid optimizations have been integrated into egcs. Think of it as the "Really Experimental EGCS."

So the upshot of all this is that we can scratch gcc-2.8 from the above list soon. My guess is that the FSF will release a new gcc-2.8 identical to the latest egcs, and egcs will either continue development separately from gcc (with occasional releases of gcc based on the egcs updates), or that egcs will simply be renamed gcc.

We will still need 2.7.2.x for anyone keeping up with 2.0.x kernels. We still might want pgcc for optimizing x86 code. We still want egcs/gcc for compiling things when we don't trust pgcc.

valid reason for the version jump (1)

Chris Pimlott (16212) | more than 15 years ago | (#1925085)

Sure it is. This is a radical codebase change here, just calling it 2.91 would be a big misconception.

Here is the babelfish translation: (1)

Praxxus (19048) | more than 15 years ago | (#1925086)

Was that translated into English, or Yoda-speak? ;)

--

I hope this is good (1)

Mr T (21709) | more than 15 years ago | (#1925087)

When EGCS started, I thought it was awesome because it would be competition and GCC had a lot of shortcommings that some competition might fix (not the GCC isn't great but ..)

EGCS had done a lot and it is a great compiler, it has been my main compiler for quite a while and it has been my only compiler since kernel 2.2 came out. I haven't had any problems with it, some of the newer more experimental CVS versions are a little rocky but the release versions are usually pretty stable.

Now what I'd like it better documentation on the compiler, particularly the internals. I've always thought that it was fairly difficult to enhance and contribute to the compilers because none of the internals seem to be documented anywhere. No IR documentation what-so-ever to my knowledge, you just have to look at the source code.

C++ is not (a superset of) C (1)

AT (21754) | more than 15 years ago | (#1925088)

In theory you don't need a C compiler, right? A C++ compiler ought to be able to compile all your C source code.

C and C++ are seperate languages. You do indeed need seperate compilers. Valid C programs can compile into something completely unintended when compiled by a C++ compiler. Granted, most of those C programs are brain damaged to begin with...

Gcc/egcs has completely seperate front-ends for C and C++. That said, they share a common backend code generator (along with FORTRAN, Java, Chill, ObjC, etc). I think they are currently merging some common functionality in the egcs front ends, but the parsers will always remain distinct.

C++ is not (a superset of) C (1)

AT (21754) | more than 15 years ago | (#1925089)

A language. It was donated by Cygnus to the egcs project as an example of how to create a new front end. I think it originates as a proprietary language one of their embedded customers use, although I could be wrong.

Developers accepted GNU (1)

AT (21754) | more than 15 years ago | (#1925090)

In order to contribute code to GNU projects that are copyrighted by the FSF -- like GCC -- you must sign documents stating you assign the copyright back to the FSF.

This applies to EGCS, too, so GNU is hardly arrogant in accepting this code -- it owns it! In fact, GNU is just giving it an offical stamp of approval and blessing EGCS as the main development branch.

Egcs is only just becoming stable after a long period of development. Remember that the E stands for experimental. Just like in the Linux kernel, it is useful to have a stable branch and a development branch.

does gcc support differing calling conventions? (1)

AT (21754) | more than 15 years ago | (#1925091)

Yes, GCC can generate windows code. The cygwin win32 based GCC can compile programs written to both Posix and win32 APIs. In fact you can mix them in a single program.

There is no reason why windows programs can't be supplied in source form. I think closed source shareware and freeware is the reason open source programs haven't appeared to the same extent in the windows world. There is less interest in the source due to the generally non-technical user base, so people are happy with closed source.

why "canadian" ? (1)

AT (21754) | more than 15 years ago | (#1925092)

Good question. IIRC, it was coined by the Cygnus guys. I think it may have something to do with our three-party political system.

Of course, Canada now has five significant parties, so I don't know if that works anymore :)

Can anyone confirm this? (1)

AT (21754) | more than 15 years ago | (#1925093)

Sure, here are some contrived examples (indentation is left as an exercise). In each case C and C++ will give different results.


int main() {
printf("%d\n", sizeof('a'));
}

int main() {
int foo;
foo = 4 //* */ 2
+ 1;
printf("%d\n", foo);
}

Executive summary? (2)

AT (21754) | more than 15 years ago | (#1925094)

Can anyone sum up the differences between egcs and gcc and explain why they haven't been combined up until now?

Here is a list of new features in egcs 1.1:
Link [cygnus.com]

canadian? (2)

AT (21754) | more than 15 years ago | (#1925095)

Canadian is the unusal case where the build platform, host platform and target platform are all different. e.g. Building a 68k compiler that will run on Sparc on an x86 box.

So can linux 2.2 compile with egcs now? (1)

meldroc (21783) | more than 15 years ago | (#1925096)

The 2.2.x series kernels compile just fine with egcs. The reason the 2.0.x kernels wouldn't compile wasn't the fault of egcs, it was the fault of the kernel - too much not-quite-ANSI-standard C code that egcs rejected. There are patches available for the 2.0.x kernels that fix these issues, but the 2.2.x kernels are better anyways.

CPU name (1)

Cowards Anonymous (24060) | more than 15 years ago | (#1925097)

vi /usr/src/linux/arch/i386/Makefile

Incredible good news (1)

swilly (24960) | more than 15 years ago | (#1925098)

ANSI C++? Have you got a time machine that the rest of us haven't heard about? Because as far as I know, C++ still is not an ANSI standardized language.

ANSI finally got around to standardizing C++ a few months ago. I'm not sure, but I think most of the holdup had to do with how templates were implemented.

Check out Stroustrup's Third Edition, it covers ANSI C++.

XEmacs (1)

maw (25860) | more than 15 years ago | (#1925099)

There's been a thread in comp.emacs.xemacs about that over the past week or so.

It doesn't look especially hopeful, which is really a shame. Competing projects are all well and good to a point; when they are as similar as gnu emacs and xemacs are, it becomes wasteful.

When xemacs 21.0 comes out (RSN) I'm afraid that I will probably defect from using gnu emacs and switch to it. It's still Free Software, and it has a lot more features. *sigh* I really do want to be loyal to the FSF, but they make it difficult at times.

basic summary (1)

rullskidor (27874) | more than 15 years ago | (#1925100)

Im not so experienced but you are very wrong about alot of things. C and C++ are to different things, you do need both. Egcs is based on gcc and is more efficent and better, the reson everyone don't use it is because its relatively new, some think it doesn't generate as good code as gcc(I don't know) but its unfortunatly mostly focused on the the Intel platform so us non intel lovers don't get as much optimations as with the normal gcc, this was the case a while back atleast...

canadian? (1)

furrer (29920) | more than 15 years ago | (#1925101)

What is a "canadian cross?"

You should be using vi! (1)

DonkPunch (30957) | more than 15 years ago | (#1925102)

Just kidding! I knew someone would post something like this EVENTUALLY.

(Oh dear. I've probably started one of those 16-level deep vi vs. emacs threads, haven't I?)

Why egcs and gcc 2.8 split in the first place (1)

BIFFSTER (31667) | more than 15 years ago | (#1925103)

From what I've heard (and this is all hearsay), the guy who used to be in charge of gcc 2.7 and 2.8 actually did do some work on the compiler, but he ONLY did it for his paying customers, and didn't release any of the modified source back into the FSF tree.

I've also heard assertions that the only reason gcc-2.8 was released as quickly as it was is because of the pressures of the egcs release.

Two cheers... (1)

Porky Pig (32612) | more than 15 years ago | (#1925104)

It's not arrogant. egcs used gcc 2.8 as its
foundation, and also their page has clearly stated
that eventually everything they did would find
their way back into gcc. Their relations work
both way and mutually beneficial.

RH5.2 has gcc *and* ecgs (1)

SpinyNorman (33776) | more than 15 years ago | (#1925105)

gcc is gcc (2.7.2.x - for kernel builds)

g++ is ecgs (1.1.2 ?)

Of course you can use "g++ -x c" to use ecgs for C as well as C++.

Finally no more gcc 2.7.2 (1)

RNG (35225) | more than 15 years ago | (#1925106)

Finally!! If I remember corerctly, my RH 5.2 distribution installed gcc/g++ 2.7.2 which may be a fine C compiler, but an aboluteley worthless C++ compiler as it doesn't support most modern features (such as member templates, etc.). I've never understood this default and am glad that egcs is finally becoming 'official'

Nice (1)

SYS2066 (37710) | more than 15 years ago | (#1925107)

I too have had problems using both GCC and EGCS in Linux, not to mention the problems it caused when I tried to install PGCC. One over-arching compiler should make things easier.

Have anyone noticed any differences in performance by compiling the Linux kernel with EGCS or PGCC?

// Simon
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?