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.
strip just does symbols (Score:1)
Re:egcs is more correct name (Score:1)
not the GNU C Compiler for precisely this reason.
Using gcs and egcs was considered, but "gcc" was
selected as the best name.
Jeff
Re:Linker too? (Score:2)
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.
C9X support (was Re:transgression) (Score:2)
Please try to get your facts right ... (Score:4)
(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.
Cygnus, egcs & gcc (Score:4)
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
Re:transgression (Score:1)
Re:strip (Score:1)
ostringstream (Score:1)
Re:Linker too? (Score:2)
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.
Questions (Score:1)
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
Also, EGCS c++ has some bugs... (Score:1)
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]
PGCC/EGCS/GCC-2.9 (Score:3)
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
Re:transgression (Score:1)
Re:linux-gnu can be fixed with sed (Score:1)
Re:data on the subject (Score:1)
almost 4 meg for "Hello World"? That's just... incredible.
Re:PGCC/EGCS/GCC-2.9 (Score:1)
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.
Re:strip (Score:1)
Re:transgression (Score:2)
Re:C9X support (was Re:transgression) (Score:1)
transgression (Score:1)
strip (Score:1)
Re:They implemented namespace, AFAIK (Score:1)
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.
Re:ostringstream (Score:1)
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 ?
Re:transgression (Score:1)
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.
Re:PGCC/EGCS/GCC-2.9 (Score:3)
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.
Re:PGCC/EGCS/GCC-2.9 (Score:1)
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).
They implemented namespace, AFAIK (Score:1)
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:
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"
Broken STL?! Oh, no . . . (Score:1)
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.
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"
Re:MSVC++ 6.0 SP9 (Score:1)
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"
Define "better" and "average" (Score:1)
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"
Cygwin, mingw32, etc. (Score:1)
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
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
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
Re:Linker too? (Score:1)
Re:what does the gcc command mean then? (Score:1)
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
Re:transgression (Score:1)
---
Re:Please try to get your facts right ... (Score:4)
--Per Bothner bothner@cygnus.com.
Re:Development model (Score:2)
Re:Linker too? (Score:1)
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-2.0.7.so
The system is a Debian slink system, by the way.
Re:nmake for linux? (Score:1)
I target both win32 and linux... I *do* love the msvc6 editor... so I use that, but build from the command prompt...
Re:transgression (Score:1)
Re:transgression (Score:1)
Re:Linker too? (Score:1)
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.