Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
GNU is Not Unix

GCC-2.95 in July 66

Bananenrepublik writes "On this page, the EGCS steering committee has posted the official schedule for the transition from egcs to gcc-2.95. So expect gcc-2.95 in early July. " It looks pretty aggressive. I wish the team luck, and eagerly await the improved compiler.
This discussion has been archived. No new comments can be posted.

GCC-2.95 in July

Comments Filter:
  • by Anonymous Coward
    Strip only removes symbols. This sounds like there is unnecessary object code being included.
  • by Anonymous Coward
    gcc now stands for the GNU Compiler Collection,
    not the GNU C Compiler for precisely this reason.

    Using gcs and egcs was considered, but "gcc" was
    selected as the best name.

    Jeff
  • by Anonymous Coward
    OK, more detail is in order. Using a bunch of libraries, but only bits and pieces from each gcc yields are large static binary. If I cut and paste the bits and just link in those the binary is much smaller. If I use shared libraries the binary is much smaller, but after the dynamic link at run time it is just as big in memory.


    In the M$ case there is no significant increase in size with the non cut and paste version. The linker seems to only grab what it needs.


    I use -O and strip afterwards for these tests.


    Dont misunderstand...I use dynamic libraries usually, but certain customers prefer static binaries and are concerned with the size. Also, I push UNIX (although not always Linux, SMP isnt there yet compared to IRIX and Solaris) over Win32, but again some customers are just mired in their Win32edness.
  • by Anonymous Coward
    The current EGCS snapshots have some support for the new C standard ( C9X [c9x.org]) . But well... it is just a beginning and a lot of basic C9X [c9x.org] features are missing (the Glibc2.1 misses many C9X [c9x.org] functions, too, especially with wide chars concerns) . I hope GCC 2.95 will finally have all the features of the final comitee draft. As that standard will soon officially replace the current C language definition, GCC have to follow it. Having a decent C9X [c9x.org] compiler on Linux is the best way of learning properly the new C language revision.
  • by Anonymous Coward on Saturday May 15, 1999 @06:00PM (#1890671)
    (1) If there is something called "Cygnus Inc" it has nothing to do with Gcc. The name you are looking for is "Cygnus Solutions". If you want to be informal, you can say "Cygnus" - but don't add "Inc"; if you add "Inc", get the name right. (While "Cygnus Solutions" is looking for a new company name, I don't think one has been chosen yet.)

    (2) Cygnus is *not* the maintainer of Gcc. The maintainer of Gcc is the Egcs steering committee. The steering committee contains individuals, but no companies are members. Some of the steering committee members are Cygnus employees, including the technical manager (I forget his official title), Jeff Law. Other members belong to other organizations.

    While this is not an official statement, I am a member of the Egcs steering committee, and (until next Wednesday) a Cygnus employee.
  • by Anonymous Coward on Saturday May 15, 1999 @08:44PM (#1890672)
    I believe it is important to clear up a few issues
    that have come up on this thread:

    1. It's Cygnus Solutions, not Cygnus Inc. At
    least until our name is changed.

    2. Cygnus contributes to egcs, but does not
    control egcs. egcs is controlled by the
    egcs steering committee which includes
    people from a variety of different backgrounds.

    http://egcs.cygnus.com/steering.html

    It is important to realize that while Cygnus
    does have representation on the egcs steering
    committee, it does not have a majority on the
    egcs steering committee.

    3. The egcs project was already in the process of
    putting a release together. It was originally
    to be called egcs-1.2. However with the
    egcs/fsf merger we decided to rename the
    release gcc-2.95. So July may not be as
    aggressive as one might think.

    4. The development model of egcs is not changing.
    Some changes will be necessary as part of the
    egcs/fsf merger, but the basic development
    model used by egcs will not be changing.

    Jeff Law
    Cygnus Solutions
    egcs project
  • I think they made it quite a bit stricter on some inline asm things, which broke some parts of the kernel. pre-2.2 kernels has "DO NOT COMPILE WITH EGCS" all over em or something :)
  • by Micah ( 278 )
    I could be wrong, but doesn't 'strip' just take out debugging information? I don't think it takes out unused functions/variables. That's called 'smart linking'. Borland's DOS compilers have had them for AGES. Why doesn't the GNU linker???
  • When is libstdc++ going to implement ostringstream??? I'm getting tired of using ostrstream...
  • As someone else pointed out already, try running strip on the binary, or compile with -s which does the same thing.

    Also, I think that a lot of Windows code is shared DLL's no matter how you link it, so there might be an apples to oranges comparison here depending on what type of application you're building.

  • by Tim ( 686 )
    (Sorry if this posts twice, I hit the return by accident)

    I was wondering if anyone knows where there is a good overview of the *nix C++ compiler variants and their implementations of the standard. I haven't had much time to keep up with the latest and greatest compiler versions, and am now woefully out of date.

    Any help is appreciated.

    -Tim
  • I think that you meant 331372 bytes and 3296 bytes.

    Take a look at

    http://www.cco.caltech.edu/~ja fl/jx/egcs_complain.html [caltech.edu]

  • by Iggy ( 1156 ) on Saturday May 15, 1999 @04:11PM (#1890679)

    I was wondering if someone could clarify a few points for me about PGCC, EGCS soon to be GCC-2.9.....

    1) What is the connection between PGCC and EGCS. I know that PGCC is based on the EGCS code and that the improvements from PGCC are rolled back into the EGCS code base, but how do the two compare on producing optimized code for Pentium/PentiumII machines. Does PGCC have code that doesn't go back into EGCS or does, for example, EGCS 1.1.2 have all the improvements from PGCC 1.1.1 in it?

    2) Has anybody done any basic benchmarking of the two ??


    If anybody has any answers... then please enlighten me :))

    P.S Yes, i know this isn't a mailing list or bulletin board, and the questions are slightly off topic, but please indulge me !!!


    Iggy
  • That's autoconf, not egcs.
  • Why fix it? The GNU refers to glibc, as Linux is only a KERNEL. It will not say "gnu" if you use libc5 or libc4, or write your own for example.
  • C++ hello world linked with just libc: 3296 k

    almost 4 meg for "Hello World"? That's just... incredible.

  • If I'm not mistaken, there is little pgcc code that rolls back into egcs. pgcc offers better optimisation for Pentium-class chips, although I'm not entirely sure about the details. By passing it -march and -mcpu options, you can get it to use Pentium-only (or whatever-only; I think it even does MMX now?) instructions. But the biggest problem with gcc was that it assumed that you had a lot of general purpose registers. This is fine for a lot of architectures, but not so hot for i386 and friends. pgcc I think addresses some of the i386 deficiencies, but I couldn't tell you exactly how it optimises for Pentium-class processors.

    As for benchmarking, you'd best go to the pgcc homepage [ml.org], but I've heard improvements from 2% to 30%. The places where you'll find a lot of improvement (10%-30%) would be stuff like bzip, gzip, tar, stuff like that...stuff that doesn't really do much besides compute.
  • Try strip -s
  • EGCS put gcc on speed :-)
  • The current EGCS snapshot is in freeze soon and will become 2.95. That is, if it's not in the snapshot, it probably won't be in 2.95.
  • what sort of awful thing did egcs do to gcc?
  • Ever use the strip command on that static binary?
  • Hi, I'm the coordinator of the Free Trek project (see web site above) and our game is portable betwen Linux and Windows (and Solaris and other UNIX too with little trouble).

    I use MSVC++ 6.0 for the Windows port, but wish I didn't have to. If you need to use the Standard Template Library, you're only hope to compile is to get STLPort (www.stlport.org) and cross your fingers. Debugging that crap is horrible because the error messages are completely un-helpful.

    Microsoft has a long way to go before their development tools are enterprise ready.
  • Why don't you go read the egcs web pages ?

    If you're really sooo impatient to get a standard C++ library, I think you can find out about the libstdc++ mailing-list, find out the state of affairs, and maybe even contribute yourself ?
  • Actually there's much more to a C/C++ compiler than a puny linux kernel, but then I'm on slashdot, so what should I expect ?

    The extended asm story is very simple: it was somewhat hackish in gcc 2.7/2.8. Poorly documented, and error-prone.

    The checks egcs added should have been there all the time. What gcc did was take those badly constrained asm statements, and spurn out some code. Sometimes it worked, sometimes it did NOT, depending upon the vagaries of the optimizer. This is known as *broken* source... you know, like all these parts in the C standard that read `undefined behavior'.

    Now, egcs complains about this kind of `undefined behavior'. Once you've read the fine documentation, and know a bit about that specific assembler, it's usually a matter of 30 seconds to fix a broken extended asm construct.
  • by espie ( 10901 ) on Saturday May 15, 1999 @07:19PM (#1890692)
    [Apologies for family name spelling, I'm doing this from memory...]

    No actual relationship between Pgcc and egcs, except that Mark Lehman is a frequent contributor to the egcs mailing-list...

    Most recent pgcc versions have been distributed as a somewhat largish source patch to the corresponding egcs snapshot.

    Actually, the difference is not that large... several factors are at hand:
    - sloppy diffs, so that, e.g., generated files account for a large part of the diff,
    - improvement to the compiler user interface. Pgcc does have a much larger set of help messages and framework.

    Once you remove those two unnecessary parts, you'll find out that pgcc's diffs are not THAT large.

    As far as speed goes, the difference is decreasing, as everything that's safe is incorporated into egcs (remember that pgcc has some higher, experimental level of optimizations that may be `broken'), and there are some fairly interesting intel developments in egcs these days (Joern Ronnecke's work for instance).

    Oh yes, there's also the point that all the world is not intel, so the compiler has to continue working properly on other targets...

    If you read the pgcc documentation, you'll notice that the improvement over gcc is not always `dramatic' (NOT 30% always, not even on average).

    If you want to find out for yourself, that's easy: Marc has been working on compiling a benchmark suite that's available from the same cvs repository that egcs is.
  • For what its worth:

    1.) pgcc has a bunch of the old pentium optimizations that Intel put together and patched into some really old gcc (2.4? something a long time ago). Various people have moved the patches forward and what not, and their current layout is contained in the pgcc patches, which I take it, haven't made it into egcs mainstream, because their stability at high levels of optimization isn't guarenteed.

    2.) On a PII 233, depending on the numerical calculation you're doing, you can get 5% speed boost or so. Nothing major.

    I've used both without any noticable problem, but have not seen any large speed difference in the two. (If you're doing heavy numerics, it's probably worth it to investigate pgcc.. otherwise, no).

  • If that's a "transgression", uh, well, I don't quite know what to say.

    Hopefully, within a few years, somebody will implement the f*cking standard, especially WRT templates.

    We need an industry-wide organization to require vendors to prominently display the following information:

    "Our Fucking Compiler is Broken in the Following Ways:
    • [arbitrary list of template features]
    • [more template features]
    • M... o... u... s... eee..."

    Like, truth in advertising or something.


    If I may go charging blindly off-topic, does anybody know offhand how badly broken MSVC 6 is with templates? v5 is a mess, but I'm hoping that with 6 they took a break from adding useless bells'n'whistles to the IDE (and removing useful ones from the help system), and put a couple of guys on fixing the compiler for a week or so. We don't have v6 at work because we don't use templates that much, and we're too busy to "take advantage of productivity features". I mean, "productivity" is great if you've got a lot of time on your hands, but we have to ship stuff so we just write code instead. We've already got our hands full avoiding the "productivity features" in v5. The last thing we need is more of them.

    v5 seems to have a few quirks with resolving overloaded functions in derived classes, too. Or maybe it was my own error, mixing overloads and virtuals. Aarrgghh.


    "Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"

  • I use MSVC++ 6.0 for the Windows port, but wish I didn't have to. If you need to use the Standard Template Library, you're only hope to compile . . .

    Oh, lord. Is it that their STL implementation (Dinkum?) is broken, or the compiler's template implementation breaks a good STL implementation, or is it just incompatible with older versions? I can't think offhand of any MSVC 5 template problems that require you to write code that would break in a good implementation, but I'm far from an expert on templates.

    I seem to recall reading that the ANSI STL differs enough from previous versions to be a problem -- or in other words, we're in a transitional period when the Standard (capital 'S') is non-standard (small 's'). So to speak. :) In an abstract way, I admire the committee for being willing to break people's code, but that doesn't mean I'm gonna enjoy "fixing" mine.

    Damn, I use the STL a lot. I don't do anything arcane or clever with it, but I do use it.


    Microsoft has a long way to go before their development tools are enterprise ready.

    :)

    Unfortunately, they don't often seem to be going in the right direction. I read an intervew with the guy in charge of that project. He's a total pod person. Nine out of ten of his answers mentioned either "innovation" or "all the great features of Windows". I mean, verbatim, "all the great features of Windows", that exact phrase, over and over. He also thought that portability was a waste of time, because most developers only have one computer on their desks anyway (maybe that's not precisely what he meant, but it looked like that was what he was getting at and I was too horrified by then to pay close attention). Like all things that Microsoft people say, it made me unspeakably depressed for several days after reading it.


    "Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"

  • The main one I have noticed was that they managed to break some system DLLs like MSVCRT.DLL.

    Um, yeah, I may have heard something like that . . . Or maybe i heard about an entirely different instance of them breaking system dll's. :)


    the breakage (changes in the behavior of malloc/free)

    What kind of changes?


    MSVC++ 6.0 SP2 seems to fix that problem . . .

    What SP are they up to by now? IIRC SP2 was this winter, for a product released around October or something. Wow.


    using cut-and-paste while debugging crashes the debugger

    To be fair, that's just the IDE, not the compiler -- but it's still hilarious. MSVC6 is supposed to let you edit and recompile on the fly while debugging, isn't it? That almost sounds useful.


    "Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"

  • Um, what don't you like about gcc?

    What do you like about MSVC?


    Failing that, can you at least name some things which in your opinion might make one compiler better than another?


    I mean, I've used both and for most of my purposes I don't see much difference, except that cl.exe knows to name the executable after the file with main() in it, but with gcc I have to tell it "-o exename". I hope you don't think that's a major issue. Innocent and poetic soul that I am, I don't pay much attention to the size of the executables these things barf up.


    Or are you just rattling people's cages? If so, you can do better, I'm sure. Try gun control. That's always a good one. Here's an example:

    "GCC was obviously designed by a whining, socialist liberal gun-control advocate. That's why it doesn't support namespaces: Because the liberals want to force us all to live together and be equal."

    :)


    "Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"

  • Why don't you use the CygWin port (it includes egcs) for Win32?

    Mmm, yeah, egcs does namespaces, which mingw32 (or at least the version I have) does not.

    mingw32, if you haven't run into it, is yet another win32 port, which uses the MS c runtime which comes with windows. I don't have the URL handy. Last I looked at the page (months ago) there was some kind of talk there about folding egcs into it.

    Anyhow, I do have cygwin at work, but I haven't bothered at home (the difference is the T1 :), and also that I have Linux and BeOS at home). It's cool, I really like it. Still, I'm not so sure about the morality of providing a good command line shell in windows; it makes it easier to keep using it. OTOH I do windows development, so Linux isn't really an option for doing that. So cygwin is really just making my life easier. It's cool to be able to conveniently tar/gzip things to send to friends who don't do windows.

    But why do I still use MSVC for my own stuff? Well, I like to make sure things are portable. I try to make everything compile with both gcc and MSVC. I also like MSVC's text editor. I just do, deal with it :) It's also neat to compare the behavior of the two when you get into relatively dark corners like member templates and whatnot. They're both broken in different ways! It's cool to find what works with both. Maybe I need to get a life.


    "Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
  • And who really cares all that much about the size of static binaries? If you're compiling static binaries, size obviously isn't a big concern.
  • Try 'gcc source.f' or any other . supported by the compiler collection.
    It compiles all of them, with the right front end. So 'gcc' doesn't mean 'C compiler' and hasn't for a long long time.
    TA
  • awful? Since when is making a better compiler a bad thing?
    ---
  • I don't know why my correction was listed as from "Anonymous Coward". I wrote it.
    --Per Bothner bothner@cygnus.com.
  • As far as I've read, the development will continue in much the same way as has been done with egcs.
  • It seems to me that it is library organization problem rather than a linker problem. After all, the linker do just the simplest thing: get in object, find all unresolved symbols, jam in all objects that provides any of the unresolved symbols and repeat. It seems to me that the library contains too much inter-dependencies, which cause most of the library object files to be included into the final binary. Can anybody confirm or disprove this?

    By the way, I cannot reproduce the results shown in other posts. My hello world compilation gives 89k stripped static binary and 3k stripped shared binary. Here's what I used:

    > g++ --version
    egcs-2.91.60
    > ls /lib/libc-*
    /lib/libc-2.0.7.so

    The system is a Debian slink system, by the way.
  • There's GNU make for win32 (cygnus or mingw32 tools)...

    I target both win32 and linux... I *do* love the msvc6 editor... so I use that, but build from the command prompt...
  • I think it was the code fork. But you'd think not that that's over, they would be more concerned about the transition
  • I meant now that that's over
  • I am not a guru, but I have experienced the same situation observed with the linking of static libraries. It's amazing to me this information isn't more widely known -- perhaps it's obvious to the gurus and therefore never written down, but that doesn't help the rest of us.

    KEY PIECE OF 'SECRET' KNOWLEDGE: The GNU linker is designed to be used with 1 global object per object file.

    You can produce object files with lots of global objects, but they won't be linked intelligently beyond the first one.

    I define intelligent linking as including the object in the executable only if it is needed.

    The GNU linker only applies intelligence to the first global object per object file, and any global objects beyond that just get thrown into the executable regardless of whether they are needed or not. The actual rule might be slightly different from my observation, but the idea that only the first global object is treated intelligently is definitely true. That is how you end up with the enormous Hello World program.

    A global object is defined as something like a function or a global variable. This is why you see many professional libraries composed of many tiny source files -- 1 function per file.

    What I don't know is how to extend this concept to C++ -- is the global object the member function or the class itself? Do you have to split up the member functions into separate files? And don't even try to ask me how to put specialization of a template function into a library.

    In summary the poster does have a valid point: Visual C++ has no limitations about 1 global object per object file, and therefore is a much more flexible tool for someone who is creating a static library.

    I'm not impressed that in all the noise generated not a single person had anything of substance to say about his comment.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...