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!

GCC 3.0 Released

CmdrTaco posted more than 13 years ago | from the third-times-the-charm dept.

Programming 210

Phil Edwards, GCC Developer wrote in to say: "The first major release of the GNU Compiler Collection in nine years, GCC 3.0, is finished. There is a long list of new features, including a new x86 back-end, a new C++ library, and a new C++ ABI, to pick my three favorites. Note that the GCC project does not distribute binary packages, only source. And right now the server is heavily loaded, so if you intend to get the source tarball, please /. one of the many ftp mirror sites instead. Plans for 2.95.4 (bugfix release), 3.0.1 (bugfix release), and 3.1 (more user-visible features) are all in progress." MartinG points to this mailing list message announcing the upload.

cancel ×

210 comments

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

Re:Umm... (1)

Anonymous Coward | more than 13 years ago | (#143876)

Be realistic... Any new major release, particularly something as complex as GCC, is -bound- to have a few bugs in it. There are only so many possible situations you can test something like this in before you call it 'good enough'.

Fortunately GCC handles having multiple versions installed simultaniously rather well, so you can have 3.0 installed to take advantage of all the new features, AND have 2.9x (your pick..) installed for kernels, system tools, and anything that absolutely must work right.

Alpha ? (1)

Anonymous Coward | more than 13 years ago | (#143877)

Their "New Features" page hasnt mentioned Alpha at all. Same stuff from 2.95.x ? Hopefully they just missed to mention it. Since the Gnu stuff does not compile cleanly with ccc and ccc is not available as source (make world with a binary-exception would suck, anyway), this would be a catasrthroy (as 2.95.x was on Alpha) ? Anyone Infos ?

...is no problem at all.... (1)

Anonymous Coward | more than 13 years ago | (#143878)

...because I'm still using Red Hat 6.0 with GNOME and Enlightenment and emacs 20.3.1 with the recommended patches.

So I'm using the very best of 1999. So what? Everything works and it runs the Linux version of Alien Crossfire, so what else do I need?

People upgrade way too often. Staying several versions behind ensures reliability.

I'll probably upgrade to Red Hat 8.1 sometime in 2003, depending on what I'll need to run by then.

DDoS (1)

Anonymous Coward | more than 13 years ago | (#143879)

"please /. one of the many ftp mirror sites instead."

This ISN'T the kind of statement you want to make, now you have proof of a planned DDoS.

Re:time for .0? (1)

Anonymous Coward | more than 13 years ago | (#143880)

Go to the gcc 3.0 page at gcc.gnu.org for links to benchmarks.

Re:how much stuff with this break? (1)

Anonymous Coward | more than 13 years ago | (#143881)

It's not just KDE. A lot of GNOME programs contain C++ too, as does NS 4, Mozilla, the BB window manager, and many others. This isn't going to be nearly as bad as the glibc transition, but I do think it's going to be enough of a headache to warrant a clean install.

Re:Linux kernel (2)

Anonymous Coward | more than 13 years ago | (#143885)

Yes. See the changelogs.

Re:Why does GCC require so much memory? (2)

Anonymous Coward | more than 13 years ago | (#143886)

My guess is they are focussing on features and compatibility and being free as in beer and speech rather than heavily optimizing code and processes at this time. On the other hand good programming practices which they seem to be embracing are steadily bringing preformance increases. Sure it may not be up to MSVC in speed but you can bet that given enough time and versions it will.

Since you seem to have a technical inclination you might want to look at the source and see for yourself. Even a grep/diff between the present and last two versions may prove enlightening.

pingmeep

Re:Performance increases in final code? (3)

Anonymous Coward | more than 13 years ago | (#143889)

2.96:

hello world
0.01user 0.00system 0:00.00elapsed 142%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (52major+9minor)pagefaults 0swaps

3.0:

hello world
0.01user 0.00system 0:00.00elapsed 125%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31major+11minor)pagefaults 0swaps

time for .0? (2)

HeUnique (187) | more than 13 years ago | (#143891)

Well, it seems like all the upcoming Linux distributions are going to .0 now (Redhat 8.0, Mandrake 9!, SuSE 8.0) - as all the stuff are not backward compatible with 2.X (gcc 2.96 is also not compatible with 3.x nor 2.x)

Has anyone done any performance tests? some benchmarks maybe? it would be really interesting to see this GCC against the upcoming commercial Intel C/C++ compiler..

partially correct (HP-UX) -you need a K&R compiler (4)

emil (695) | more than 13 years ago | (#143901)

AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).

On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C). One then uses xgcc to generate a GNU-compiled gcc. I don't know why xgcc is not normally installed and used, but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).

HP-UX natively includes a K&R (non-ANSI) C compiler. It is almost useless, but it will successfully compile gcc. On most other commercial UNIX systems, if you lack a compiler, you must rely upon someone who has a compiler to generate a verstion of gcc for you (which accounts for the popularity of packaged gcc versions on many platforms). This can also be complicated by licensing of the system include files and libraries.

No (1)

Per Abrahamsen (1397) | more than 13 years ago | (#143905)

It is the only major C++ fature not yet implemented.

C99 has dynamic arrays (1)

Per Abrahamsen (1397) | more than 13 years ago | (#143906)

... but I'm not sure they implement it exactly like GCC.

It is worse than that... (2)

Per Abrahamsen (1397) | more than 13 years ago | (#143907)

In short, the 2.9x line (which Redhat admittedly bastardized a bit by grabbing a snapshot and calling it 2.96) will still be fixed for bugs.
Acutally, Red Hat GCC 2.96 is much closer to GCC 3.0 than to GCC 2.95.3. Except for the C++ library, which is basically the same as in 2.95.3. This put Red Hat in an odd situation, they will have to track the 3.0 compiler and the 2.95 library, if they want to remain compatible with their own 2.96 release. However, they employ many of the best GCC engineers, so if anyone can do it, it will be them.

I'd prefer them to swicth to 3.0 at the earliest possible location, though.

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (2)

Per Abrahamsen (1397) | more than 13 years ago | (#143908)

It also compiles with GCC, with a warning. The code used to be correct, but the standard commite changed the rules.

Solaris is also affected (2)

Per Abrahamsen (1397) | more than 13 years ago | (#143909)

Which means you must compile your C++ applications with the same GCC version as your C++ libraries.

"a repeat of the gcc-2.96-REDHAT fiasco?" (3)

Per Abrahamsen (1397) | more than 13 years ago | (#143911)

Yes. That is the point of the "gcc 2.96 Red Hat fiasco". The C++ library and ABI has been changed in 3.0 in order to conform to the C++ standard, as well as new cross-compiler C++ ABI standard, and to be much more efficient. The problem with the Red Hat release was that it was released half-way through that process, so it would be both forward and backward incompatible with the official FSF releases.

In most other ways, the unofficial gcc 2.96 is an improvement over 2.95, and for C code compatibility is as good as between any two releases of gcc. Mostly GCC 2.96 catches a few bugs that 2.95 failed to notice.

Re:g++ 3.0 compilation speed (3)

Per Abrahamsen (1397) | more than 13 years ago | (#143912)

Programs that uses iostreams will tend to be slower, because of the new (ISO mandated) template based iostream implementation. In particular, a "hello world" program will tend to compile much slower, since it spend most of its time in the header.

Other programs can compile much faster or much slower, depending on what the bottleneck used to be, and what features they excersize.

There are several implementations of precompiled headers for GCC, which are likely to give a large boost in compilation speed when one of them is selected for inclusion.

Re:How about PGCC and EGCS.. (4)

Per Abrahamsen (1397) | more than 13 years ago | (#143913)

GCC is basically a new name for EGCS.

I don't know about PGCC, but since GCC 3.0 has a brand new ia32 backend with focus on Pentium II performance, chances are that PGCC is no longer relevant.

Re:so (2)

Sabalon (1684) | more than 13 years ago | (#143915)

Good point. Since at some point the first GCC had to be cross-compiled or bootstrapped from a non-gcc, non-gpl, and therefore probably commercial/proprietary compiler, does that mean that all off gcc is non-gpl derived?

So, since the original gcc was non-gpl derived, then everything built with gcc, while it may be gpl derived, is truly non-gpl derived.

So, if you wanna build an application based on gpl code and not distribute it does that mean it's okay?

(Yes...for the GPL or death people, this is a joke)

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (2)

Malc (1751) | more than 13 years ago | (#143917)

Wow: they're really going to fix that bug? They've known about it for several versions of MSVC (4, 5, 6), but seemed unwilling to change it. Fixing it will surely break a lot of code and presumably require a new compiler directive to build old code unmodified. This bug has been irritating me for a long time as I've been writing code that must also compile on the Mac, and every now and again I slip up and forget to declare a loop variable before the loop, and then try to use it after the loop.

Why does GCC require so much memory? (3)

Malc (1751) | more than 13 years ago | (#143918)

From http://gcc.gnu.org/news/inlining.html (linked to in the list of new features):

"As a result, the compiler may use dramatically less time and memory to compile programs that make heavy use of templates, such as C++ expression-template programs. One program that previously required 247MB of memory to compile, and about six minutes of compile time, now takes only 157MB and about two minutes to compile. "


I remember try to build the TAO (the ACE ORB) a few years ago. Under Linux using GCC, a couple of files consumed all of virtual memory (requiring 250MB of memory). When I had sufficient, it would take my 128MB machine 45 to 70 mins to compile those particular files (lots of swapping). The same files under Windows with MSVC would take less than 20MB and thus compile in under a minute. What is GCC doing that requires so much memory? Is it me, or is this new inliner (that is such an improvement) still a memory hungry hog? Why? (Technical answers preferred).

export keyword (1)

Kenneth Stephen (1950) | more than 13 years ago | (#143919)

Does anyone know when support for the C++ "export" keyword is expected? Is someone working on this already?

Something else gcc let me do... (1)

Derek Pomery (2028) | more than 13 years ago | (#143920)

int main(int argc, char *argv[])
{
int ary[atoi(argv[1])][atoi(argv[1])];
return 0;
}

Convenient, no? Instead of doing a for loop and malloc()ing through it?

But completely uncompilable on any sane compiler. :)

New libraries... Wahoo! (3)

Lally Singh (3427) | more than 13 years ago | (#143924)

I'm really glad to hear about the new C++ libraries. The compiler's been pretty good about compliance so far, but the libraries have sucked for quite a while now. Glad to see the improvement...

--

Re:Umm... (2)

yendor (4311) | more than 13 years ago | (#143926)

The first thing you do when you've released something is work your ass off to get it right.
This isn't supposed to take 3 months like M$ sometimes seems to think it should.

The way programmers are pushed today the first x.0 is mostly more of a beta than a release.

Not a problem realy if you got more time at bugfixing but since the company that's behing them don't earn money unless it's out there we won't see a change before that changes.

// yendor

--
It could be coffe.... or it could just be some warm brown liquid containing lots of caffeen.

Re:Umm... (2)

garcia (6573) | more than 13 years ago | (#143931)

at least they say ahead of time that they will be releasing a "bug fix" version. Not like other programs that don't release bug fix versions for years ;-)

But don't forget (5)

Ian Schmidt (6899) | more than 13 years ago | (#143935)

The very reason GCC 3.0 is out now rather than in 2005 is precisely because RH "jumped the gun" and submitted hundreds of bugfix patches to GCC 3.0 in the process. Meanwhile Redhat's GCC 2.96-81 is less buggy in my experience than 2.95.2 and the new features are great.

Re:Umm... (1)

grahamm (8844) | more than 13 years ago | (#143936)

gcc 3.0 should compile kernels with no problems. Was linux kernel compilation not one of the release criteria for gcc 3.0?

In related news (2)

funkman (13736) | more than 13 years ago | (#143942)

Slashdot already talked about this [slashdot.org] . (Actually the link is stating that 3.0 is rumored to be released soon)

They're looking professional!!! (1)

Hammer (14284) | more than 13 years ago | (#143944)

We all know that there is no chance of finding / fixing all bugs prior to release. Assuming that all monumental showstoppers have been addressed there are likely a whack of unknown "unintended features" as well as a few known defects that is not yet fixed.
Stating upfront that "we know about these bugs and plan to fix them in 3.0.1" is really professional behaviour. And it gets the compiler ot to a broader group for use/test...

Re:Umm... (4)

Tim C (15259) | more than 13 years ago | (#143947)

I'd say they're just being realistic. No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal. The best you can realistically hope to do is catch all the real show stoppers. (Assuming that you actually do want to release the product at some point, that is)

Having said that, this is the first time (that I can remember) that I've seen an officially-planned x.0.1 bugfix release announced at the same time :)

Cheers,

Tim

Re:how much stuff with this break? (4)

Raphael (18701) | more than 13 years ago | (#143948)

[...] the big question is "how much stuff is this going to break?

Not much, hopefully.

The only major thing that can affect the binary packages is the new C++ ABI. But for plain C programs, there should be no big difference. Most of the Linux programs and libraries are written in C and should not be affected significantly. This could be a problem for Qt and KDE packages, though.

See also the list of caveats [gnu.org] on the GCC web site.

Re:Here's the funny thing... (2)

JabberWokky (19442) | more than 13 years ago | (#143951)

I have a feeling quite a few people are gonna be red in the face over this one.

I doubt it. There *is* no C99 compliant compiler... and since C and C++ standards almost always seem to contradict themselves in one or two spots, it's unlikely that there ever will be one.

And it's not such a bad thing - the face="" paramater to the font tag is invalid HTML. I guess the web in general should be red in the face?

--
Evan "And I'll invent *another* dozen specs *after* lunch!" E.

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (3)

Galahad (24997) | more than 13 years ago | (#143953)

You've got it backwards. MS VC has it wrong too. the declaration of i in your example is scoped with the body of the for loop. 'i' does not exist after the closing brace of the for-loop.

This is per the ANSI/ISO C++ standard.

But can you debug your programs? (2)

Kevin S. Van Horn (29825) | more than 13 years ago | (#143954)

My problem with gcc's C++ compiler has been that there is no workable compiler for it. Gdb just falls to pieces when you try to debug C++ code (it can't find symbols, it can't handle user-defined operator overloads, sometimes it gets mixed up and gives you the wrong values for variables, etc.) Is there an update to gdb to go with the new gcc that provides reasonable support for C++?

Re:Umm... (1)

Penrif (33473) | more than 13 years ago | (#143957)

Having said that, this is the first time (that I can remember) that I've seen an officially-planned x.0.1 bugfix release announced at the same time :)

Hence the spooky part.

Re:so (1)

Wodin (33658) | more than 13 years ago | (#143958)

Argh! When will this bloody BSD-bashing-bot stop posting this drivel in the hopes someone will take it seriously?

Re:its all quite unambiguous... (2)

SpinyNorman (33776) | more than 13 years ago | (#143962)

Yuk! Does C99 allow nested scopes at all...

{
int i;
{
int i;

Is this legal, or a redefinition?

Re:Red Hat's problem... (4)

ajs (35943) | more than 13 years ago | (#143967)

Of course, they will do what they've always done (and every other commercial vendor with large customers does). They will distribute "obsolete" software until their next version, when they will go with the almost-latest-and-greatest that they can get to work.

You have to understand, Red Hat bowed to their customers. Many of their C++ customers told them they needed ANSI C++ compliance badly. GCC 2.96 offered that.

Red Hat has a history of working hard on the compiler, and distributing a custom version. They were the first distribution to ship egcs (remember, 6.2 ran egcs for the C++ compiler). They also did a lot of work on making egcs work for the Linux kernel.

--
Aaron Sherman (ajs@ajs.com)

Press release available (4)

bkuhn (41121) | more than 13 years ago | (#143971)

For those of you who prefer a non-hacker announcement of the release, a press release is available [gnu.org] .

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (2)

throx (42621) | more than 13 years ago | (#143973)

Which is why I always code these sort of loops as:

int i;
for (i = 0; i < x; i++) {
...
}
for (i = 0; i < x2; i++) {
...
}

Just to avoid problems on either compiler.

Just to avoid problems on either compiler.

its all quite unambiguous... (1)

thogard (43403) | more than 13 years ago | (#143974)

the scope of anything in C is defined inside the {} set or the semi-implied {...} that contains the whole program. Some early C compilers would gernate a new frame with every {. some embeded compilers still do.

So the int i should be in the outside scope.

But...
for(a;b;c) {x;};
is the same as:
a;
while(b) {x; c;}
so the int i should be in the inside scope.

does that clear it up in an unambiguous way?

I'm glad you see it my way (what ever that is)

Performance increases in final code? (3)

hattig (47930) | more than 13 years ago | (#143975)

Has anyone done any performance metrics using code generated by the "all new singing dancing x86/PPC/ARM backends"?

Re:GJC! GJC! (1)

ncaustin (49860) | more than 13 years ago | (#143978)

" I've written in clean, attractive Java code (to do stuff like rename files"

er you wrote a Java program to rename files?
The best think about Java for Linux developers
is that we can get access to programs that
previously would have been only been Windows binaries.

GJC does not help that at all. I for one won't
be using it, the JDKs are faster enough for me
and I do more than rename files!

Linux kernel (2)

chrysalis (50680) | more than 13 years ago | (#143979)

Is it safe to compile the Linux kernel with GCC 3.0 ?

Re:Linux kernel (3)

chrysalis (50680) | more than 13 years ago | (#143980)

I've got some troubles with the newly compiled kernel. Sometimes, the kerboard blo

so (4)

British (51765) | more than 13 years ago | (#143984)

So how did they compile the first version of the GCC compiler? Seeing is that there was no prior GCC compiler first?

Re:so (3)

alannon (54117) | more than 13 years ago | (#143987)

This reminds me of the currently popular theory of how life arose, by simply taking constituant elements, heating them up and zapping them with lightning until they form amino acids and eventually proteins.
My theory, however, involves a freak accident involving a cage full of monkeys, a box of hand-held hole-punchers, a large stack of stiff paper and a punchcard reader.

Re:how much stuff with this break? (1)

Velox_SwiftFox (57902) | more than 13 years ago | (#143989)

Well, you can't expect everyone else to write special stuff to support Redhat's poor choices, can you?

They, and anyone choosing to use Redhat, have only themselves to blame if there are problems.

Re:how much stuff with this break? (2)

Velox_SwiftFox (57902) | more than 13 years ago | (#143990)

Troll? How is this a troll? Sorry, I'm confused, I thought was just common sense.

And it is the policy of the gcc developers, isn't it, and the developers of the linux kernel itself that Red Hat had to also supply their "kgcc" secondary system-space compiler for?

Or is there someone out there who thinks the people are obligated to support the "gcc-2.96-REDHAT" stuff?

Re:how much stuff with this break? (2)

Velox_SwiftFox (57902) | more than 13 years ago | (#143991)

That's what I said.

Red Hat's problem... (4)

Velox_SwiftFox (57902) | more than 13 years ago | (#143992)

So... since Red Hat jumped the gun and grabbed development releases using libs that apparently gcc will no longer be compatable with - and according to what they've said is their policy that they won't change to incompatable libs in mid-major-version - I wonder if this means RH 8.0 will come out simultaneously with 7.2, or if they are going to just skip now to 8.0?

Or if Red Hat users will now be forced to continue to use what has become obsolete software?

I'm sorry, but... (1)

tentac1e (62936) | more than 13 years ago | (#143994)

Wouldn't it be funny if with all the new features of gcc 3, you could only compile the source files with gcc 3?

Ok. It's too early in the morning for me, so I'll shut up now.

Here's the funny thing... (5)

bconway (63464) | more than 13 years ago | (#143995)

Guess what? Everyone that complained about GCC 2.96 being broken (and not reading http://www.bero.org/gcc296.html [bero.org] ) despite the fact that their code wasn't C99 complient STILL WON'T COMPILE. Now you can't complain that your code won't work because it's a developmental compiler, you'll actually have to fix it. Numerous examples of this are listed at the above URL, I'd highly suggest you try it out. I have a feeling quite a few people are gonna be red in the face over this one. ;-)

Re:its all quite unambiguous... (2)

Entrope (68843) | more than 13 years ago | (#143996)

> So the int i should be in the outside scope.

No version of the C language allows a declaration in the middle of a block (i.e. between two statements), although C++ does. Your explanation assumes that such a thing is permitted in C.

C99 specifically addresses how constructs like "for (int i=0; i10; i++) STMT" should be handled; it specifies that the compiler should treat it as if there were a new enclosing block around the "for ... STMT" that began with the declaration of the variable(s) in the init-part of the "for" loop.

So C99 says that:
for (int i=0; i10; i++) STMT
should be transformed to act like (in older C standards):
{ int i; for (i=0; i10; i++) STMT }

C99 makes it unambiguous indeed.

(I can't speak towards the ISO C++ standard, but I would imagine that they also stipulate that the scope of the defined variables ends after STMT above.)

Re:its all quite unambiguous... (1)

akihabara (70553) | more than 13 years ago | (#143997)

It's illegal because you forgot the } and }.

Re:partially correct (HP-UX) -you need a K&R compi (4)

akihabara (70553) | more than 13 years ago | (#143998)

AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).

No, it does not require such a compiler; it is required to be bootstrappable with such a compiler.

And K&R did have void. They didn't have pointer to void.

On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C).

Not really. xgcc is the name of the result of the stage1 and stage2 bootstraps; the stage2 one is created by the stage1 one (i.e. by GCC).

I don't know why xgcc is not normally installed and used

It effectively is, if you type "make install". The bootstrap process just ensures that the result of the stage3 bootstrap has identical object files as the result of the stage2 bootstrap, which formed xgcc. In other words,
that optimized GCC compiles itself into the same optimized GCC - a consistency check. Those binaries are what get installed, so it is effectively the same GCC.

but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).

Nothing to do with it. Everything after stage1 is a consistency check.

The GCC developers should thank RedHat (5)

kdgarris (91435) | more than 13 years ago | (#144004)

The fact that RedHat used an earlier snapshot of this compiler allowed for extensive testing early in the development process, resulting in many bug-fixes being made to the snapshot as well as to the pre-3.0 GCC development code.

I'm sure this release came about sooner with a lot less bugs due to Redhat's move to use the earlier snapshot in their distro.

-Karl

no binaries? (1)

willie150 (95414) | more than 13 years ago | (#144006)

So assuming that you don't have a built compiler (and thus require GCC)... what do you do? This is the only thing that I can understand needing binaries for, and it there isn't any. This don't make sense to me.

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (1)

Harri (100020) | more than 13 years ago | (#144012)

The C++ standard specifies that the for scope ends at the end of the for loop. The only compiler I know of that gets this wrong is Visual C++. That is a bug with Visual C++ and will be fixed in 7.0 AFAIK.

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (3)

Harri (100020) | more than 13 years ago | (#144013)

This post [google.com] lists the non-compliance issues that VC7 will ship with. The for-loop scoping problem isn't there.

Re:so (1)

gdr (107158) | more than 13 years ago | (#144018)

So how did they compile the first version of the GCC compiler? Seeing is that there was no prior GCC compiler first?
It's compilers all the way down!

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (1)

marble (120353) | more than 13 years ago | (#144020)

Actually, MSVC has a command line switch that turns on the correct behaviour (that i goes out of scope at the end of the loop). It's just that if you turn it on it can't compile it's own headers, so it's somewhat useless...

Re:Question (3)

marble (120353) | more than 13 years ago | (#144022)

The C Programming language was originally standardised in 1989, and this was known as C89 (and also as C90 - long story...) In 1999, the C language was updated with some new features and library functions. This is now known as C99.

Re:Question (5)

RevAaron (125240) | more than 13 years ago | (#144025)

What is Google?

Re:Umm... (4)

istartedi (132515) | more than 13 years ago | (#144026)

No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal

Unless you're Microsoft; then you're an incompetent, obnoxious, FUD-spouting dinosaur and every bug that escapes is an indictment of you, your business practices, design methodology, family heritage, preference for breakfast cereal, haircut and anything else associtated with you or anyone you have ever met, slept with, laid eyes upon, or casually passed on the street.

g++ 3.0 compilation speed (3)

martinde (137088) | more than 13 years ago | (#144029)

Did they manage to speed up g++ at all? In the prerelease versions, I was seeing compilation times that would put g++ 3.0 at about 2-3 times slower than 2.95.2. And 2.95.2 was significantly slower than any egcs version. Anyone know if there are plans to address this?

Re:no binaries? (2)

Salsaman (141471) | more than 13 years ago | (#144031)

Well you build gcc 3.0 with gcc 2.x, and then you use your newly built gcc 3.0 to build gcc 3.0 again.

Simple really.

Re:so (5)

langed (142123) | more than 13 years ago | (#144033)

Of course, they did the same thing that is done in the first stages of building gcc as a cross-compiler: build a compiler that compiles the compiler you'll eventually use. This early-stage compiler need not support all of C, only the parts that the compiler uses.
if you look in this Makefile, you'll see that in stages one and two it builds a program called xgcc, which it later deletes, but not before it compiles your cross-compiler.

the nice thing about doing this is that the compiler that is finally built when the entire compilation process is complete doesn't have to necessarily be "real C" in the source code. It could be a nice intermingling of any number of languages. It isn't, but it does give them that freedom.

So to review:
gcc (installed) -> xgcc -> new gcc compiler

FOR loops: a question, ANSI C++, C++98, C++99.... (2)

MrMeanie (145643) | more than 13 years ago | (#144034)

Certain compilers, including previous releases of GCC and Metrowerks Codewarrior allowed the following:

for (int i = 0; i x; i++)
{
[....]
} //scope of int i ends here so....

for (int i = 0; i y; i++) //...redeclaring int i doesn't blow up
{
[....]
}

Does GCC 3.0 still allow this?
The above code 'feature' is not allowed under the ANSI C++. Under ANSI C++, the int i variable scope will continue beyond the for loop. IMHO the ANSI standard does not make sense WRT this issue. This is commonly thought to be a bug in the ANSI C++ spec (or so I am led to believe).
I do not know about C++ 98/99/whatever standard. Any URLs anyone?

Re:Question (1)

bigdavex (155746) | more than 13 years ago | (#144036)

C99 [onetelnet.ch] is an update to straight C-standard. It picks up a few features of C++ (e.g. // comments) and general mishmash. Much of it is already supported by modern compilers.

Kuro5hin [kuro5hin.org] ran a story on this. [kuro5hin.org]

Re:so (5)

TeknoHog (164938) | more than 13 years ago | (#144040)

The first GCC compiled itself. There is nothing contradictory here since, according to Novikov (see his book The River of Time) the present can be affected by future events.

This process is somewhat similar to the beginning of the universe, which according to Perl zealots started when tiny bits of eval() statements arose from quantum fluctuations. These immediately produced more and more eval()s, resulting in a big bang of code. Eventually, other functions appeared, forming the Universe as we know today.

There is also a controversial theory which asserts that the first GCC was written with assembler, and that the first assembler was written in binary code by Real Men (TM), but the evidence for this is questionable.

--

Re:FOR loops: a question, ANSI C++, C++98, C++99.. (1)

cant_get_a_good_nick (172131) | more than 13 years ago | (#144042)

This is controlled on the command line with -ffor-scope and -fno-for-scope. This has been around for a while (at least since 2.8.1 days) when the spec wasn't that firm on this (in fact gcc's default has changed).

see Options Controlling C++ dialect [gnu.org] in the manual.

Re:so (1)

cant_get_a_good_nick (172131) | more than 13 years ago | (#144043)

Maybe Mel [astrian.net] wrote the first gcc in hex in his head.

Re:how much stuff with this break? (1)

cant_get_a_good_nick (172131) | more than 13 years ago | (#144044)

The gcc 2.96 stuff was a RedHat-only f.u.b.a.r. mess. They took a development snapshot, called it 2.96 and released it to an unsuspecting public. Don't blame the gcc folks for RedHats probably very unwise decision.

Re:Umm... (2)

Karn (172441) | more than 13 years ago | (#144045)

Why would a groups plans to fix a .0 release spook anyone? Who do you know that released a .0 verison of something and didn't have bugs?

insert Homer-donut sound here (1)

pizen (178182) | more than 13 years ago | (#144049)

gcc...yum
---

Re:Red Hat's problem... (5)

Erasmus Darwin (183180) | more than 13 years ago | (#144051)

Or if Red Hat users will now be forced to continue to use what has become obsolete software?

The existence of a new version of software does not (unless you're dealing with the ugly, ugly world of MS Office documents and their lack of backwards compatibility) automatically break older versions. You will not go bald, get cancer, or get attacked by a pack of rabid dogs just because you're using an older version of gcc. You will not see:

[erasmus@localhost ~]$ gcc -o test test.c -Wall
gcc: Version 3.0 has been released. You must upgrade. Sorry.

Furthermore, from the Slashdot blurb (right at the top of the page -- you don't even have to click a link), we've got the following:

Plans for 2.95.4 (bugfix release), 3.0.1 (bugfix release), and 3.1 (more user-visible features) are all in progress.

In short, the 2.9x line (which Redhat admittedly bastardized a bit by grabbing a snapshot and calling it 2.96) will still be fixed for bugs.

Also, for a production system, new, untested code is considered unacceptable. There are bugs in the 3.0 version of gcc, period. Over time, they will get fixed. But just like running an experimental kernel (or even the very first new stable release of a previously experimental kernel) is a great way to shoot yourself in the foot, you don't want to jump to gcc 3.0 unless you've got a reason to use it. And people who have a reason will generally be able to locate and install a copy of gcc 3.0, anyway. Hell, give it a few weeks and they should be able to locate and install an RPMed copy of gcc 3.0. And I'm sure there are people out there who will need gcc 3.0 -- it just won't be the core Redhat demographic, yet.

In short, did the people at work bitch at me for running RedHat 6.2 on our production machines at work? No. Would they have bitched if I had upgraded to 7.0 when it came out, broken things in the process, and used the excuse that they just need to wait a year for RedHat 7.2? Hell, yes. Even Slashdot does something similar -- there's plenty of lag between the latest version of Slashcode and what's running on Slashdot.

Solaris? (1)

11223 (201561) | more than 13 years ago | (#144053)

Does the new C++ ABI affect solaris? Will my KDE/etc. stop working if I update from 2.95.3 to 3.0?

i wonder... (1)

athlon02 (201713) | more than 13 years ago | (#144054)

that's kewl that there's an hc11 and hc12 port now, since those are some nice little microcontrollers... i wonder how easy/hard it would be to port it to other hc## chips, anyone know? i mean would it be just a matter of using the hc11 or 12 port as a template and swapping a few opcode names & values and recompiling? (since i've never gone as far as constructing a full fledged compiler, just some simpler parsers).

Multi language (1)

marcovje (205102) | more than 13 years ago | (#144055)


I see language changes (Java integrated, Fortran improvements), but I kind of miss the years old Gnu Pascal project?

Re:But can you debug your programs? (1)

marcovje (205102) | more than 13 years ago | (#144056)


Try the CVS. I also managed to get (Free) Pascal support running with post 5.0 GDB CVS on FreeBSD with some patches.

When I last checked (6 months ago), the CVS was in a pretty usable form.

From the GCC 3.0 Caveats (1)

wmulvihillDxR (212915) | more than 13 years ago | (#144057)

The Chill compiler is not included in GCC 3.0, because of the lack of a volunteer to convert it to use garbage collection.

As in, "Chill, to the next episode/version"

Re:so (1)

BlowCat (216402) | more than 13 years ago | (#144058)

GCC can be compiled with other C compilers, unlike most stuff you can find on FreshMeat. GCC still uses K&R syntax for the code that is used in the bootstrapping process.

Re:g++ 3.0 compilation speed (1)

NoOneInParticular (221808) | more than 13 years ago | (#144060)

About compilation speed, does anybody know whether g++ 3 supports the 'export' keyword now? That would help quite a bit in reducing compilation time.

And on a related note, does it still need approximately 2 Gigs of internal memory and the better part of the weekend to optimize heavily templatized code*?

Thanx

Re:g++ 3.0 compilation speed (1)

NoOneInParticular (221808) | more than 13 years ago | (#144061)

Ok, forget the second question, someone above mentioned that it now only takes 1 Gig and a day, sigh.

Time to recompile RedHat (1)

C0vardeAn0nim0 (232451) | more than 13 years ago | (#144065)

This time with an official release of GCC, not the broken development release they used in RH 7.0...

--

Re:Umm... (3)

oconnorcjo (242077) | more than 13 years ago | (#144067)

The way programmers are pushed today the first x.0 is mostly more of a beta than a release.

Actually what is happening is that as the tools we create and use become more and more sophisticated (and thus more lines of code in use), the harder it becomes to catch all the possible things that could go wrong in an application. With big projects like the Linux Kernel, GCC, Mozilla (now in beta), KDE, Gnome, XFree86- it is just realistic to assume that even though the developers worked very hard for a stable release, people will find bugs.

how much stuff with this break? (2)

kenfrid (244776) | more than 13 years ago | (#144068)

This being the first "major" release of the gcc in years, the big question is "how much stuff is this going to break?" Are we going to have a repeat of the gcc-2.96-REDHAT fiasco? I can see it now: "Sorry, this package compiled with gcc-3.x, you appear to have a 2.95 based system, please upgrade." Or the other way around. Download a source tarball and see "this code written specifically for gcc-3.x. You need at least that version to compile."

gcj now integrated (4)

iloveAB (247945) | more than 13 years ago | (#144070)

I use a lot of JAVA, and it looks like we will finally have a full JAVA front-end for gcc with dependency generation (for automatic makefiles).

Re:so ("Which came first ...) (1)

fnkybuda (251034) | more than 13 years ago | (#144071)

... the chicken or the egg. I egged the chicken and then I ate his leg." Beastie Boys - Pauls Boutique - Eggman

Re:GJC! GJC! (2)

dasmegabyte (267018) | more than 13 years ago | (#144074)

Sorry for the high geek quotient in the previous message, I think the five cups of coffee injested since the news of GJC have kind of warped my perception of, well, anything. In my zeal, I forgot to paste a link to this HELL LEET COOL BITCHIN SWEET ASS new GNU tool...http://gcc.gnu.org/java/ [gnu.org] .

GNU & JAVA: The Network is the OS.

GJC! GJC! (5)

dasmegabyte (267018) | more than 13 years ago | (#144076)

GNU JAVA COMPILER!

I can finally write in Java and not get made fun of by my elite C++ hax0r friends!

In case you weren't aware, GCJ is the first Gnu toolset for Java, and it's not just a nasty rehash of Sun's stuff...it's JRE, JIT and NATIVE CODE COMPILER rolled into one. They have an odious refutation of the Write Once Run Anywhere creedo which I don't necessarily agree with (the guy must be writing some pretty fierce code if he's had problems like he mentions, I've done distributed Java with the Swing libraries for about a year and never had a problem that wasn't related to Netscape sucking). What I care about, though, is the speed ups. Finally, all my keen little utility programs I've written in clean, attractive Java code (to do stuff like rename files, play music and so on) will run as fast as OS level stuff. I intend on compiling the sweet ass netbeans [netbeans.org] ide as soon as they get AWT working. Maybe I'll finally be able to get it to run as fast on my shitty Celeron windows machine as it does on my MACOS lappy.

GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO.

simd? (1)

nilstar (412094) | more than 13 years ago | (#144078)

It's been a while since I've used GCC, does anyone know if it has inline assembly support for SSE and SSE2 on the intel side?

Question (2)

Tachys (445363) | more than 13 years ago | (#144079)

What is the C99 standard?

EGCS is now officially obsolete! (1)

archnerd (450052) | more than 13 years ago | (#144081)

Hallelujah! Praise the Lord! Woohoo!

When's It going to be Mandrake ;-) (1)

A Commentor (459578) | more than 13 years ago | (#144084)

So when's Mandrake going to incorporate this into their distribution?

With Mandrake 8.0 problems with Adaptec SCSI Controllers, I'll be staying with 7.2 until they get it fixed up and hopefully include this new compiler..

Re:Linux kernel (1)

HuruRudo (460968) | more than 13 years ago | (#144085)

Well, I have successfully compiled the kernel...
I haven't seen so many oopses before. :-P
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?