Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

egcs to become gcc 127

Posted by CmdrTaco from the its-about-time dept.
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.
This discussion has been archived. No new comments can be posted.

egcs to become gcc More

egcs to become gcc

Comments Filter:

  • Kernel +, Distro ++, Mesa --. (Score:1)

    by Anonymous Coward
    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! (Score:1)

    by euroderf ( 47 )
    gcc and egcs rpm's can't seem to coexist without conflict, but now I have a good reason to choose egcs ...
  • 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).

  • What do you mean, it existed before him? The term "open source" was only coined recently : Stallman has been advocating Free Software since the early eighties. There was no Free Software/Open Source movement before him.

    *sigh*

  • Yeah, free software was around RMS but there was no real "movement" as such, like there is today.
  • 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.
  • 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.
  • 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).

    ---

  • 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.
  • "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
  • 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.

    --

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

  • Emacs w/ GTK+ support would be soooo nice.
  • Indeed the truth that is.
  • Ok, well C++ is designed to be a superset of C and compile all legacy C programs fine, but apparently it didn't work out quite that way. Legacy C support is why the class keyword was added with its members defaulting to private, because changing the struct keyword to default to private would break old C programs.

    For your first example, that puzzles me. I seem to have read something about characters being (in some cases) considered integers in C, which could be why sizeof('a') returns 2 in C. getch(), getc(), and several other functions return a character as an int with a high-order byte of 0. C++ apparently decided to be more sane and report sizeof('a') as being equal to sizeof(char).

    For your second example, that's the unavoidable side effect of adding a new commenting style. It's theoretically possible to break some code, as you demonstrated, but if you were doing that in your C code to begin with, you have problems =)
  • Is there any particular reason that 'a' in C is an int and not a char? I see that in the functions that I mentioned (getc(), putc(), getch(), etc.), but it's puzzling.
  • 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
  • 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

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

    -Doug
  • 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

  • Date of ANSI Approval: 7/27/98

    ...says my electronic copy of the standard.

    OG.

  • XEmacs (Score:1)

    by zerblat ( 785 )
    Okay, now all we're waiting for is GNU Emacs and XEmacs to merge ;)
  • If you have a read at the gcc documentation included with EGCS you'll find details of the machine configs and stuff.

    It really isn't that tough though...I've been modifying EGCS to support some new instructions on the Motorola ColdFire(a m68k derivative). My changes which include a couple of new target switches were restricted to 4 files. m68k.h, m68k.md, m68k.c and m68k-none.h in gcc/config/m68k

    When you start digging into it it isn't that bad....I'm a Windows Pascal/Delphi programmer and I figured it out ;)
  • 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.
  • 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.
  • geez claudius...
    --
    Man is most nearly himself when he achieves the seriousness of a child at play.
  • Well, compared to gcc 2.8, gcc 3.0 will include at least one new language (Fortran), a working C++ compiler, the C++ library, a test suite, support for many more platforms, and code for major new optimization techniques (not yet fully utilized, though).

    If this doesn't justify a new major version number, nothing does.
  • 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?

  • 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.

  • 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/
  • 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.

  • 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? :)
  • And having C++ automatically typedefing all the structs would lead to an endless amount of errors I think.

  • XEmacs (Score:1)

    by mikpos ( 2397 )
    That's not entirely true. z00m over to here [umd.edu] and read the part where he talks about merging Emacs and XEmacs.
  • 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."
  • 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.
  • 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.
  • 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.

  • 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? (Score:4)

    by Ray Dassen ( 3291 ) on Tuesday April 20, 1999 @09:18AM (#1925046) Homepage
    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).

  • 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?
  • Sure, I am not. Sprechen sie Yoda?

    Eh, Bumbled for Babel Fish sure.

  • 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)
  • 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? ;)

    --
  • 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
  • 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.
  • 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.
  • 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.
  • 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.?)
  • But it already is 2.91. gcc -v on a egcs release will say something like gcc 2.91.63 (egcs 1.1.2). GCC_MINOR (or whatever it is) is 91. So why the change?

  • 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

  • Not sure about the involvement of Intel with the Gygnus/egcs team, but I can comment on the Pentium optimisations in pgcc. The differences between pgcc and egcs are gradually fading, as more of the optimisations are folded into the latter.


    Chris Wareham
  • 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
  • I thought Intel was working with cygnus on more robust optimizations for gcc. PGCC was really just a proof of concept
  • 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.
  • I tried compiling pgcc 1.1.2 with egcs 1.1.2, egcs 1.0.3 and gcc 2.7.2 and got the same internal error each time.
  • With pgcc the binaries are usually larger but faster. I think this is because it aligns data as doubles rather than words or something like that.
  • There has been a short discussion on this a while
    ago in com.emacs.xemacs (which I actually started ;). So, there ARE people interested in this and there ARE people in contact concerning this. But the ones who know what they are talking about say it will be a hell of a work to do this ...
    IF it will happen, it will take quite a long time, I think (the more I'm involved the longer the time *g*). Go and read the archived NGarticles at
    http://www.xemacs.org/list-archives/xemacs/

    regards
    kampi

  • 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).

  • 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.

  • Three new languages: Fortran, Java, and Chill. There's also been some work to integrate GNU Pascal, though that's still not in the tree.

    We talked about using "gcs" for the name, it's no longer a C compiler. But people know the name "gcc". Think of it as standing for GNU Compiler Collection.

    No final decision has been made about the version number, but when we were talking about starting egcs, some folks wanted to call it gcc3 immediately (but this would have pissed off a number of folks so we didn't do it).

  • No final decision has been made as to whether the planned egcs 1.2 will come out as egcs 1.2 or gcc 3.0 or gcc some other number.

    Also, June is not a promise: it will come out when it is ready.

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

    by JoeBuck ( 7947 ) on Tuesday April 20, 1999 @12:22PM (#1925069) Homepage

    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?

  • 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".

  • FSF made gcc. FSF used gcc to make GNU. GNU is a software distribution. See how that works?
  • 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?
  • 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

  • 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
  • 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++.
  • Yea, change /usr/src/linux/arch/i386/Makefile, look down for your arch. K6 is under the "CONFIG_M586TSC:" label
  • Gee, now it looks like the people putting together that "non-GNU" Linux distribution will have to find another compiler.

    My heart is breaking for them. Really. :)
  • The code would not necessarily be less efficient. However, a C++ compiler cannot successfully compile all valid C programs.
  • 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?

  • Thanks, AC, that helps. You saved my day. :-) So time to send a bug report to the pgcc folks?
  • sizeof('a') is 4. Oh, wait. 8. Oh, 1.
    It depends. It's just that it's the same
    as sizeof(int).

    There's a reason for this. In C, 'a' is an int,
    and you can do hacky stuff like 'abcd' on some
    platforms and expect to get results. C++ changed
    it so you could overload functions to take char
    arguments and get the results you expected.

    C++ was not intended, as of a fairly long time
    back, to be a perfect superset, just to be "fairly
    compatible".

    C++ *will not* include the C9X features, which,
    for me, means that C9X will be the one I use,
    because C++ is a lot uglier.

    (Disclaimer: I just might be a little
    biased.)
  • I believe "Human Translation" meant translated by a human, and not by babelfish. :-)

  • pgcc still separate (Score:4)

    by crow ( 16139 ) on Tuesday April 20, 1999 @10:45AM (#1925084) Homepage Journal
    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.
  • Sure it is. This is a radical codebase change here, just calling it 2.91 would be a big misconception.
  • Was that translated into English, or Yoda-speak? ;)

    --
  • 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.

  • 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.
  • 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.
  • 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.
  • 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.
  • 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 :)
  • 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);
    }

  • 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? (Score:2)

    by AT ( 21754 )
    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.
  • 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.
  • vi /usr/src/linux/arch/i386/Makefile
  • 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 (Score:1)

    by maw ( 25860 )
    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.
  • 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...
  • What is a "canadian cross?"
  • 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?)
  • 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.

  • 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.
  • 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!! 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'

Slashdot Top Deals

I'd rather just believe that it's done by little elves running around.

Close