Slashdot Mirror
GCC 3.3 Released
devphil writes "The latest version of everyone's favorite compiler, GCC 3.3, was released today. New features, bugfixes, and whatnot, are all available off the linked-to page. (Mirrors already have the tarballs.) Let the second-guessing begin!"
mmm i'll install this one only cuz it rhymes ;)
just for information re-compiling glibc 2.3.2 with gcc 3.3 fails. i don't see the point releasing a compiler or standard glibc which doesn't allow the existing compiler to be used to compile it.
Caveats
The preprocessor no longer accepts multi-line string literals. They were deprecated in 3.0, 3.1, and 3.2.
The preprocessor no longer supports the -A- switch when appearing alone. -A- followed by an assertion is still supported.
Support for all the systems obsoleted in GCC 3.1 has been removed from GCC 3.3. See below for a list of systems which are obsoleted in this release.
Checking for null format arguments has been decoupled from the rest of the format checking mechanism. Programs which use the format attribute may regain this functionality by using the new nonnull function attribute. Note that all functions for which GCC has a built-in format attribute, an appropriate built-in nonnull attribute is also applied.
The DWARF (version 1) debugging format has been deprecated and will be removed in a future version of GCC. Version 2 of the DWARF debugging format will continue to be supported for the foreseeable future.
The C and Objective-C compilers no longer accept the "Naming Types" extension (typedef foo = bar); it was already unavailable in C++. Code which uses it will need to be changed to use the "typeof" extension instead: typedef typeof(bar) foo. (We have removed this extension without a period of deprecation because it has caused the compiler to crash since version 3.0 and no one noticed until very recently. Thus we conclude it is not in widespread use.)
The -traditional C compiler option has been removed. It was deprecated in 3.1 and 3.2. (Traditional preprocessing remains available.) The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.
General Optimizer Improvements
A new scheme for accurately describing processor pipelines, the DFA scheduler, has been added.
Pavel Nejedly, Charles University Prague, has contributed new file format used by the edge coverage profiler (-fprofile-arcs).
The new format is robust and diagnoses common mistakes where profiles from different versions (or compilations) of the program are combined resulting in nonsensical profiles and slow code to produced with profile feedback. Additionally this format allows extra data to be gathered. Currently, overall statistics are produced helping optimizers to identify hot spots of a program globally replacing the old intra-procedural scheme and resulting in better code. Note that the gcov tool from older GCC versions will not be able to parse the profiles generated by GCC 3.3 and vice versa.
Jan Hubicka, SuSE Labs, has contributed a new superblock formation pass enabled using -ftracer. This pass simplifies the control flow of functions allowing other optimizations to do better job.
He also contributed the function reordering pass (-freorder-functions) to optimize function placement using profile feedback.
New Languages and Language specific improvements
C/ObjC/C++
The preprocessor now accepts directives within macro arguments. It processes them just as if they had not been within macro arguments.
The separate ISO and traditional preprocessors have been completely removed. The front-end handles either type of preprocessed output if necessary.
In C99 mode preprocessor arithmetic is done in the precision of the target's intmax_t, as required by that standard.
The preprocessor can now copy comments inside macros to the output file when the macro is expanded. This feature, enabled using the -CC option, is intended for use by applications which place metadata or directives inside comments, such as lint.
The method of constructing the list of directories to be searched for header files has been revised. If a directory named by a -I option is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system header files are not defeated.
A few more ISO C99 features now work correctly.
A new function attribute, nonnull, has been added which allows pointer arguments to functions to be specified as requiring
And "cant compile kernel with gcc 3.3" messages started to appear on lkml. Is it me or gcc team goes for quantity rather than quality that they even postponed many bugs ( like c++ compile time regression ) to gcc 3.4 to release 3.3...
Never learn by your mistakes, if you do you may never dare to try again
I hear they have added in some more advanced, and aggressive bounds checking. Now when i screw up something i wont have to wait for a seg-v to tell me that pointer moved a little too far.
Although it dosnt seem to work with glibc....this is quite annyoing, although it probably will be fixed and re-released in a few days
I'm waiting for SCO to show it's copied code before I pick up any GNU software.
-... ---
I believe this version has stricter checking. It is probably a good idea for everyone with programs out there to do a quick recompile and see if there is something you can improve or error messages you can fix.
If you think deeply enough, you will have no single direction for your outrage.
Does this release break binary compatibility?
There is one. Its called Visual SlickEdit, it costs $249 dollars.
erm... KDevelop? Amongst others, there's quite a few good ones now.
The optimiser has been vastly improved and ....
The following changes have been made to the IA-32/x86-64 port:
SSE2 and 3dNOW! intrinsics are now supported.
Support for thread local storage has been added to the IA-32 and x86-64 ports.
The x86-64 port has been significantly improved.
If you wan't compile time performance look at
Precompiled Headers
thank God the internet isn't a human right.
You DO realize that most of the problems compiling the Linux kernel with succeeding releases of gcc is due primarily to the kernel team making incorrect assumptions about the kernel output...
Right?
[ home ]
Yes, this release (like all 3.x releases) is a lot slower than 2.9x was. This is particularly true for C++, to the point where the compile-time cost of standard features like iostreams or STL is prohibitive on older, slower machines. I've largely gone back to stdio.h and hand-rolled containers for writing non-production code, just to keep the edit-compile-test cycle ticking along at a decent pace.
The new support for precompiled headers will help to some extent but is by no means a panacea. There are a lot of restrictions and caveats. The good news is that the GCC team are very well aware of the compile-time issue and (according to extensive discussions on the mailing list a few weeks back) will be making it a high priority for the next (3.4) release.
Incidentally, for those wanting a nice free-beer-and-speech IDE to use with this, the first meaningful release of the Eclipse CDT is at release-candidate stage and is looking good.
Visual Studio (v6) is a really bad IDE. I prefer Borland C++ Builder from far. And Visual C++ is really abject on some aspects: why does it compiles things differently if you are in debug mode? I used VC++ to code a file compression utility. Operator precedence is not the same between debug and release compiler mode. Debug had the same behaviour than GCC, Watcom or Borland. Release mode had a different behaviour. Not nice, since it took me hours to find wherethe bug was, since you can't easily debug a release executable... Moreover, speed-optimisation nearly always produces bad code. And debugging 'const' functions in C++ make the debugger go wild. Borland had neither of those problems. And the code looked cleaner when showed by BC++ Builder. Nevertheless, what I really like is the EclipseIDE, and the IDE of BeOS.
The new breed of gcc compiler are anywhere from 3 %to 5% slower with file processing using the C++ library. So, compiling the kernel with gcc 3.x is fine, but I suspect that something like KDE which is mostly written in C++ is impacted seriously. At least, all software using the C++ library for IO (fstream) will be much slower. On the other hand, the support for C++ standards is much better so what I do is that I compile using gcc 3.2.3 to validate my C++ and then I run the real thing with a pre 3.x compiler.
That's great... but can anyone tell us what a difference all that will make? I don't really care about compile times (too much)... but will mpeg2enc or ffmpeg run faster?
BTW, there is a preliminary ebuild in Gentoo.
http://blog.grcm.net/
According to this, if your program is multi-threaded, uses spinlocks in libstdc++, and runs on x86, then you'll have to configure gcc-3.3 for a i486+ target (instead of i386) in order to make it binary compatible with gcc-3.2.x configured for a i386 target. Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)
I think you missed the "for writing non-production code" qualifier.
For a small, non-critical app which only needs minimal functionality, hand-rolling is hardly a time sink. Writing a bare-bones string or list implementation takes about five minutes, and in terms of time, will "pay" for itself after a dozen or so compiles.
Nah.
Funny as hell, though - Visual Studio is an absolute joy to use.
Compared to what?
Having your head nailed to a table?
oh brave new world, that has such people in it!
Not for me, thanks. I prefer the dynamic duo of Borland's C++ Builder/Kylix. Cross platform gui development? How you say...ah yes...w00t!
For Java, Sun One Studio (crappy name)/Netbeans (inaccurate name) floats my boat. There is a light C++ module for Netbeans but I haven't tried it...no need.
Give Kylix a try - there is a free version you know:
Borland® Kylix(TM) 3 Open Edition delivers an integrated ANSI/ISO C++ and Delphi(TM) language solution for building powerful open-source applications for Linux,® licensed under the GNU General Public License
Download it here.
Sounds like you just don't have a lot of experience compiling. The first thing you do when something acts out of spec is to clean and then rebuild. This probably would have solved a lot of your troubles. The GNU make has this bug even worse, since it only checks file size most of the time. Speed optimization has _never_ in my 5 years of using VC++ produced bad code. Please stop with the trolling and get back to learning how to use the compilers properly.
Borland C++ was okay 6 years ago, but after VC6 came out it's easy to see why it's not so great any more. Two more IDE updates and the old BC is left far behind. I'd take many OpenSource IDE's over BC. Features such as auto-completion and code collapsing have saved me a good deal of time & typing.
-]Phreak Out[-
There is one. Its called Visual SlickEdit, it costs $249 dollars.
Oh man dont spend that money....
anjuta is better and much more useable than visual slickedit as a linux based GCC ide for C and C++ and will create your project's Makefiles and everything else automatically.
I've used it for 6 months and it's easier than anything microsoft has ever written in their IDE and is certianly better than slickedit when you compare the costs.
I strongly reccomend that EVERY programmer download and try it right now... it's that good (except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?)
Do not look at laser with remaining good eye.
They don't really seem to care about not following the standard for i686. You still have to compile everything for i586 on the Via C3 Ezra chips. The specs. for i686 states that cmov is an optional feature in i686 chips but gcc still doesn't check if the cpu supports it. Of cause with the new C3 it doesn't matter, but I don't have one of those.
Not a big fault, but it would be nice not having to remember to set the cpu type to i586 everytime you compile stuff.
I know about the clean and rebuild all. I tried. But it didn't work. In fact, all the problems began when I asked people to use the const keyword to prevent some side effects at compile time. Borland C++ Builder, at the time I used it, had the code completion thing. I don't know what code collapsing is. I suspect you are talking about Borland C++, not Borland C++ Builder. I used Borland C++ 4.5 and 5, those were buggy IDEs. Worst was Watcom C++ IDE. The text editor could hang the computer 4 times a day. But you use the compiler and IDE your company owns. But VC++6 never had my preference in one aspect: it produces faster code than borland compiler.
Seems useful, though I suspect many derefernced pointers are set NULL at runtime, and so not spottable during build.
Note: I didn't change the wording above at the [sic], but I believe that this should read "all pointer arguments" instead.
sig is
Well that's rather odd then. I've had const all over the place in a couple projects and everything seemed to work just fine. I wouldn't throw out the possibility of the compiler misbehaving at this point, but I'd still guess it to be something else. Code collapsing is like being able to fold a piece of paper so that you only see the parts you want to. A lot of newer IDE's have this.
-]Phreak Out[-
I must say that when I first saw the code, it was really messy... So the cleanup was long and difficult. I remember the problem occured in a private static const function that dealt with the serial port. Code collapsing sounds a cool feature, but the VC++ we used (VC6) didn't have this. Now, I don't code in C/C++ anymore, or just for fun. I use the worst IDE I know of (even if it feature some kind of "code collapsing"): Cool:GEN to produce COBOL
Intel's compiler smokes gcc in most benchmarks (not surprising, given that Intel knows how to squeeze every last bit of performance out of their own processors). Although it is not 100% compatible with all the gcc features, and therefore can't compile the Linux kernel, each release adds more and more compatibility. I hope the day will soon come when we can compile a whole Linux distribution with the Intel compiler.
Are you sure you are not getting precedance confused with order of evaluation between sequence points?
C++ has fairly flexible rules in that regard, the much discussed (on comp.lang.c++) undefined behavior and implementation-dependant behaviour. For example i=i++; invokes undefined behaviour that may vary between compiler settings. My instinct would be that that is more likely to be the problem than compiler error in most cases. You should post the problem code to see if that is the case.
As for the mmap option... IMHO it is a little bit complicated, and glibc seems to use mmap on read-only streams anyway.
Agreed. But I see two paths to optimization (probably more--I'm not a compiler writer). First, there are optimizations that work well on all processors. Things like inline function calls, loop unrolling, etc. Second, there are optimizations that work on a per processor basis. For example, using instructions in such a way that the processor's pipelines are filled and that its branch prediction doesn't choke, etc. Clearly Intel has the advantage in making the second type of optimizations. But do you think they also have the advantage in the first type as well? The only way to find out would be for Intel to work on gcc's intel-compling mode. Then benchmarks would show which does the better job of doing optimizations of the first type.
that open source requires more skill on the part of the developer to get through the learning curve.
A greater amount of knowledge about what is happening at all levels is mandatory to make that GNU\Linux system happen.
Whether this is a but or feature probably depends on your current location on the learning curve. The more I interact with open source, the more I like the fact that there are relatively fewer secrets about what is occuring, a feature that seems lost by the time you reach the West Coast...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
If you get hopelessly confused, you could try a mailing list. If you write a good question, its highly likely the original developers will respond.
Treating casts as lvalues is a GCC extension, and an extension that has been deprecated for C++ since 3.0 because it causes problems for valid C++ code.
I believe the plan is to add a warning in 3.4 and remove it in 3.5.
Yes, sorry, I confused. This problem was about the order of evaluation. But I cannot understand why VC++6 has different oreder of evalutation, when in Debug mode and in Release mode. I won't be able to post the code because: - I wrote it two years ago - since it was problem prone, I changed it the days that followed - I don't work in the same company now When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working (in fact, it was essentialy because in debug mode VC++ was initialising data, I spent a lot of time debugging that in my first month)
The inline flag in C and C++ is a hint to the compiler that inlining this function is a good idea, just like register is a hint to the compiler.
GCC has always treated inline as such a hint, but the heuristics of how to use the hint has changed, so some functions that used to be inlined no longer is inlined.
The kernel has some function that *must* be inlined, not for speed but for correctness. GCC provide a difference way to specify this, a "inline this function or die" flag. Development kernels use this flag.
Does amazing thing for correctness, and is much easier to understand. However, it is not faster in general. It is faster at some tasks and slower at others, same on average.
It also exposes tons of errors in existing C++ programs, so expect lots of whining when GCC 3.4 is released.
GCC 3.4 will have precompiled headers (thanks Apple), which will speed compilation up a lot for project that uses them.
Apperently KDevelop is just about as good. When I was looking into it, and they have scripting in it. I loved scripting in Visual studio.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Actually, Visual Studio is a great IDE. It's one of the few things Microsoft did well. It's not easy to understand at first, but it you take the time to learn it, you'll appreciate it.
My favorite feature was the scripting ability. You could write VB Scripts (or start by recording them as a macro) to accomplish tasks. I wrote several VB Scripts that wrote out comments in the code.
KDevelop is the only thing I have seen that's close to Visual Studio. I have C++ Builder 3.0 Professional at home, but I still like the design and easy of use of Visual Studio. The C++ Builder interface is missing some things--like scripting.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
OK, I'm not a developer. I don't write code--I compile it when the tools I need as an admin aren't available as trusted binaries.
Why, for the love of god, is there a new version of the de facto standard C compiler every week or two? Why can't binary compatability be maintained? WHAT sort of changes and development occur in the land of compiling a language that (as far as I know) isn't changing??!!
This isn't a rant--these are serious questions. I don't understand why so many changes are being done to a compiler, and why it should affect me as a non-developer. What am I missing here?
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Amen. I wouldn't have thought it possible to write a product that makes CVS look like a sensible choice for source control if I hadn't seen it with my own eyes.
We used to use SourceSafe, now we use CVS. CVS is an horrific train-wreck of an application but compared to VSS it's a triumph of software engineering.
Suck figs.
Dude, that's what Emacs is for.
Still, I'm looking forward to the day when normal people don't need
C/C++ compilers anymore because everything's written in VHLLs. (The
kernel hackers and compiler/interpreter jocks will of course always
need the lower-level tools, but application developers someday won't,
just as today most of them don't need assembly stuff anymore.)
Cut that out, or I will ship you to Norilsk in a box.
The C and Objective-C compilers no longer accept the "Naming Types" extension (typedef foo = bar); it was already unavailable in C++. Code which uses it will need to be changed to use the "typeof" extension instead: typedef typeof(bar) foo. (We have removed this extension without a period of deprecation because it has caused the compiler to crash since version 3.0 and no one noticed until very recently. Thus we conclude it is not in widespread use.)
Or rather, gcc version >= 3.0 is not in widespread use.
except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?
Could that be because most programmers don't really do that much printing of code? I haven't printed out any source since my form-feed dot matrix printer died years and years ago.
That said, pipe your code through GNU enscript to print it, and it should generate some decent syntax hilights. Also, if you're interested in publishing code with hilighting to a web page, Vim can output to html using the currently selected hilight mode.
It's only software!
A lot of code will use fstream read and write.
That's the standard way to do things. Granted,
that's not high performance programming... but
that's common programming. If 90% of C++ code out there is slowed down by at least a fixed percentage, this will have a major impact.
I agree that Visual Studio is a pretty decent IDE. I've used it for years and have grown to love it.
However, after using Eclipse, I'm never going back (except if I need a good Win32 GUI resource editor).
> Windows - developer friendly. Linux - developer hostile.
Is that why Windows has 95% of the users and 60% of the developers,
while Linux/BSD/Unix (excluding Mac) have 1% of the users and 85%
of the developers? Yeah, Linux is *real* developer-hostile. The
way it hides all the implementation details makes it so hard for
programmers to get things working...
Calling Linux user-hostile would be a gross exaggeration, but at
least it would be barking up something that resembles a tree.
Cut that out, or I will ship you to Norilsk in a box.
I could almost swear I typed 30%, not 85%... sorry for any confusion.
And yes, all statistics courtesy of Flagrant Estimation Incorporated.
Cut that out, or I will ship you to Norilsk in a box.
That's a gcc extension? I've been using that in my code for years! Of course, all my code is compiled on gcc... Code like this:
*(unsigned int *)(voidpointer) = intval;
isn't valid C/C++? Or do you mean gcc allows something like this:
(unsigned char)(longval) = charval;
?
A solution to the problem with music today
Hey, don't feel bad.
:)
This happens all the time. I have stopped submitting stories since all it seems to do is give the people who run slashdot fodder to take credit for themselves.
I believe the practice of favoring one's own select group is called nepotism.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Could that be because most programmers don't really do that much printing of code? I haven't printed out any source since my form-feed dot matrix printer died years and years ago.
so how exactly do you do code reviews? we print it out, copies for each of us and sit in the conference room screaming at each other.
it's invaluable for a code review.
Do not look at laser with remaining good eye.
Okay, while libc and gcc are technically different projects, as I understand it, I agree that it would seem reasonable to drop a note to the libc folks saying "hey, gcc can't compile libc" and waiting for an update before releasing.
On the other hand, the argument that the gcc folks should make sure that the *kernel* (presumably the Linux kernel) compiles is absolutely ridiculous. The kernel has been long broken and not language-compliant. I think recent compilers can compile it, but that's very recent, and hardly the fault of the gcc people. The Linux kernel has no association with gcc, and is not an amazingly clean project. Gcc is used in far more places than Linux is -- on just about every OS and architecture in the world. Blocking a gcc release because the Linux kernel doesn't compile would be insane. Gcc is *far* bigger than Linux. It is the standard available-everywhere compiler.
When someone misuses English, do you correct them or change the entire language to fit their mistake?
It's great to hear about all these new improvements in gcc, but what I really want is a working debugger for C++ code compiled with gcc. The gdb debugger is buggy as all hell. It gives wrong values for variables, has no end of troubles with C++, and often enough when I want to print out the value of a variable it tells me that it can't access that memory, with no further explanation.
> *(unsigned int *)(voidpointer) = intval;
I don't think that code has a problem, the "*" operator uses an rvalue, so you don't actually use the lvalue of the cast.
If you had written
(unsigned int *)(voidpointer) =
I believe you would have been in extension territory.
thus, I can follow the development list.
The reason it's different from debug and release mode is that the optimizer is invoked in release mode. In debug mode, the order of evaluation is probably very straightforward and results in what you expect. In release mode, the optimizer uses the ordering flexibility between sequence points to optimize loads and stores, so the order of evaluation probably becomes different.
That said, VC++ is a hideously broken C++ compiler. I have nothing good to say about it.
A deep unwavering belief is a sure sign you're missing something...
3.2 broke binary compatability with 3.1, right? and 3.1 (modified) is what is used in OS X 10.2. Does this mean Apple will have to do a lot of munging to use 3.3?
As far as I can tell, there is nothing as good as Visual Studio for Linux. Naturally, this was a huge disappointment to me when we migrated from NT to Linux at work.
Don't get me wrong - KDevelop is a brave attempt, and coming along, but it just doesn't match Visual Studio. The most incredibly irritating thing about it is the diabolical project management. I had to hack my copy just to make it slightly useful at all, and eventually I just gave up on it. Now I use jedit, handmade makefiles and kdbg. I still miss MSDEV, though.
Fairly soon I'll try KDevelop 3 again to see how it's come along, but if you're used to Visual Studio, you will be disappointed.
I'm still trying to find a nice GUI-driven debugger, as kdbg seems rather flaky.
so it shouldn't be affected by this particular regression.
As far as I can tell, Anjuta suffers from the same problem as KDevelop - very inflexible automake-based project management. Otherwise I'd be up for using it, but the project management stuff is such a pain in the ass.
Still, I'm looking forward to the day when normal people don't need
C/C++ compilers anymore because everything's written in VHLLs
Do Java and C# qualify as "VHLL" to you? If so then you may get your wish. However, you probably meant true scripting languages.
Almost every user application except for cutting edge games could be written in Perl/tk or Python or XUL or something. Unfortunately, the ability to do this has existed for years if people aren't using it now I don't predict that they'll start.
(Aside: Back when Java first came out, I remember thinking that it seemed really ass-backwards to try to force the old "compiler" paradigm back into a world (the web) where scripting had already become ubiquitous. Obviously I underestimated the power of the "we're better than you script idiots" elite programmer mindset (And I mean elite, not l33t. The kind of people I'm talking about tend to spell things correctly (and I'm saying all of this as a former scripter who has managed to become "one of them" for the money (HDANCN?)))).
I am now in serious danger of getting modded off-topic.
where there's fish, there's cats
It is pretty easy to do with a parallel make (GNU make is fine) and a wrapper script that rsh gcc to apropriate machines. I did it back in school when I had access to lots of Unix machines.
I don't know if there is any projects to formalize this, but in these SourceForge days there most likely is.
I clicked on one of the intel ads last night and was debating wether or not to download the 'unsupported' linux version of intel C & Fortran. Mostly just to play around with.
I'm wondering if anyone here has played with intel (esp under Debian) C and has any comments on it versus GCC.
Also [on a fortran note] if it would be worth getting intel fortran for the sake of fortran 95 support, or should I stick w/ the ubiquitous [sp?] gcc/fortran 77 which runs everywhere?
Opinions, anyone?
Right now I'm busy changing all "#include" to "#include"
Umh, intended to say: changing "#include <iostream.h>" to #include <iostream>". Damn markup.
I have always been amazed that such an impressive compiler is still free. Thanks to the GCC team. You guys/gals rock!
Anonymous Cowards suck.
And why release it?
It fixes lots of bugs, obviously people who have been bitten by these bugs will want them fixed as soon as possible. And those who need the new feautures tend to need them yesterday.
All these people are developers. I do not see any reason for non-developers to care, just use the compiler bundled with your OS.
BTW the last full release was 3.1, quite some time ago. All the intermediate releases (including 3.2) have been bug fix releases with no new features.
It's a shame that no one managed to fix bug #10392 before release. Until that one's fixed, those of us who do Dreamcast hacking are stuck using GCC 3.0.4.
install both and measure. My application, a numerical simulation written in C++, was 5% slower when compiled with icc. The better benchmarks show the same thing, icc is faster for some tasks and slower for others, but expect for very specialized tasks they tend to be in the same ballpark for real applications.
The GNU make has this bug even worse, since it only checks file size most of the time.
False. GNU make checks the last file modification time. If you have any problems getting consistant incremental builds, it is probably because the Makefile has incorrect dependency information. For example, if a header file changes the size of a struct, every source file that includes it should be recompiled. An automated tool like "gcc -MM" is the best way to ensure the dependencies are correct.
The patch in the original bug post looks like this:
/* Can't remember if & or -> is evaluated first, so I added () */
- ConfigItem** ip = &(ConfigItem*)menu->data;
+ ConfigItem* i=(ConfigItem*)menu->data;
+ ConfigItem** ip =
So I guess you're right; the & operator would use an lvalue. One could code *(void*)5, but not &(void*)5.
The way I would've coded that particular code in one line is:
ConfigItem** ip = (ConfigItem**)&(menu->data);
Or the (unsigned int *) example case you gave as:
voidpointer = (void *)uintpointer;
So, I really don't see this extension as anything more than a potential way for increasing gratuitous obfuscation for the purpose of the obfuscated C contest.
A solution to the problem with music today
macosx% gcc --version
gcc (GCC) 3.1 20020420 (prerelease)
Not going to go grab the latest GCC because I wouldn't count on it to work with ObjC, MachO, and whatever else Apple may still be patching in.
Start Running Better Polls
It's a POSIX function, so it'll work on most Unixy operating systems. Check /usr/include/sys/mman.h for the prototypes.
It's a POSIX / UNIX way to do things. I'm not sure if the various Windows compilers support mmap. Under Linux and/or UNIX, you can do man mmap to find out more.
And yes, mmap is very cool. I've used it to great effect in a programming contest where speed was one of the measures. I mmaped the file and faulted it in quickly with a short loop. The overall program flew like a bat outta hell! What's really nice is that you can just refer to the file contents directly by pointer as opposed to reading them or freading them into a buffer. The downside is that it's less portable and harder to get right, which is why I don't use it for everything.
--JoeProgram Intellivision!
Fair enough; we do our reviews a little differently.
We don't do very many "comprehensive" reviews with several people going over a complete feature. Instead, every single line of code that gets checked into source control MUST be reviewed by at least one other person; preferably someone familiar enough with the code to be able to see what it impacts.
For smaller changes to existing code, a diff of the "before" and "after" code is generally enough to see what was done. Bigger changes usually end up being reviewed by more than one person, just not all at once. All of this is done on the computer.
It's not perfect, but this works quite well for our situation-- and it saves us some paper as a side-effect.
It's only software!
ahhhh, makes sense... we have many old-hairs here that require that we kill a forest weekly for every little thing.
hell they still require that we fill out time sheets online and PRINT THEM to put in their inbox.
I like your way better.
Do not look at laser with remaining good eye.
The Visual C++ compiler included in Visual Studio .NET 2003 is a vast improvement over previous versions. I believe it even compiles the loki library now. :)
.NET 2002 (which was only slightly better) but I think you probably haven't tried out the newest one yet.
Seriously, what you say is correct for Visual C++ 6 (which was god-awful) and for Visual C++
Oceania has always been at war with Eastasia.
Sounds like you've been coding to a very old pre-standard version of C++ for a long time. Don't complain that the standard keeps "refining" - what you are talking about are things that have been stable for years. Count yourself lucky that compilers actually let you get away with it all this time.
And I hope you aren't putting "using namespace std" in new code. Ugh.
--
CPAN rules. - Guido van Rossum
"...to some extent." Why give a Subject: line textbox that won't let me use all of it? Grrr.
Anyhow. One of the big speed hits for iostream code was the formatting routines. Some other reply has a subject like "if you're using fstream you're not interested in performance anyhow," which is so wrongheaded I won't even bother to read it. There's no reason why iostreams code shouldn't be faster than the equivalent stdio code: the choice of formatting operations is done at compile-time for iostreams, but stdio has to parse the little "%-whatever" formatting specs at runtime.
However, many iostreams libraries are implemented as small layers on top of stdio for portability and compatability, which means that particular implementation will always be slower.
We were doing something similar until recently. Not a complete layer on top of stdio, but some of the formatting routines were being used for correctness' sake. We all knew it sucked, but none of the 6 maintainers had time to do anything about it, and the rest of the world (that includes y'all, /.) was content to bitch about it rather than submit patches. Finally, Jerry Quinn started a series of rewrites and replacements of that section of code, aimed at bringing performance back to 2.x levels. One of the newer maintainers, Paolo Carlini, has been working unceasingly at iostream and string performance since.
So, all of that will be in 3.4. Chunks of it are also in 3.3, but not all. (I don't recall exactly how much.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
>>The preprocessor now accepts directives within macro arguments. It processes them just as if they had not been within macro arguments.
The separate ISO and traditional preprocessors have been completely removed. The front-end handles either type of preprocessed output if necessary.
This quote below makes me hopeful.
I've had trouble with this macro in gcc:
#define TRIGGER_PUSHBUTTON(c)
((PUSHBUTTON16) | 'c')
gcc doesn't like having the macro add the quotes around the character argument. Only works if you to leave the quotes out of the macro definition and require them in the macro argument.
But I have a lot of code written on AIX that uses this macro (and others like it). Porting to linux requires 'fixing' all the occurrances.
Anybody know if this applies?
Posted from my Android phone. Oh, I can change this? There, that's better...
Now I understand what Bjarne Stroustrup wrote, when he described
The standard hasn't changed since 1998.
The extensions are, in many cases, older than the standard. Now they conflict with rules added by the standard. One or the other has to give. And, of course, no matter what happens, somebody out there will declare that GCC "obviously" made the wrong choice.
If you think it's easy, why don't you give it a try? Hundreds of GCC developers await your contributions on the gcc-patches mailing list.
If you don't like it, you should demand your money back.
Again, the standard was published in 1998. The three changes you describe were decided upon even before then, and they haven't changed since. You've had 5 years to walk down to the corner bookstore and buy a decent book, or search on the web for "changes to C++ since its standardization". None of those changes are due to GCC, and trying to shift the blame to GCC only points out your employer's laziness.
You've had half a decade. Catch the hell up.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
d00d! YU0=t3h $u}{0R, I=31337 ]-[@}{0R. 101101101101!!! -g0thm011y
I've noticed in gcc 3.x that #include "header.h" looks for system header matches *before local scoped headers.
Is it just me or is that wrong and annoying?
I've had to distribute shell scripts to swap out filenames for compilation ( which wouldn't be fun to do by hand, trust me ) everytime gcc3 compiles the code base.
I don't track gcc3.x, but has this been fixed or is it intentional to cause confilcts you can't possibly predict on another system?
Here's a problem you could predict as an example:
#include "endian.h"
Then lots of odd compile errors ensue confusing the user. Also #include seemly includes -- wtf is up with that? Are these people using old/bad gcc3.x builds?
Now that you understand the problem, I strongly suggest you acquire an authoritative reference for C or C++, whichever you are using. If you can read the ISO standard, that's obviously the best resource. Electronic copies are available for about $20, I think.
What you did was rely on something the language never guaranteed. C defines a concept called a sequence point (mainly the ';' at the end of a statement, but there are other sequence points), at which point all previous expressions would have been fully evaluated. Between two sequence points, however, it guarantees nothing. So, this:
is undefined, because since '=' is not a sequence point, you don't know which value of 'i' will be used to get a[i]. In fact, as you've found out, it can differ between debug and release builds. On the other hand, this:is valid C code, because ';' is a sequence point, and 'i' is not both modified and accessed between two sequence points. C++ basically inherits all of this from C. Sequence points in C is a level of understanding that should give you chills thinking back at every line of code you've ever written.When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working
That's just sloppy. A difference in behavior between debug and release builds can be an indicator of major bugs that are merely better hidden by the debug version. The bug may still surface when the program is subjected to real world loads, or some unexpected input. It's possible that a compiler bug causes the release build to be broken, and so you ship the debug build, but not investigating is plainly irresponsible.
http://www.gnuenterprise.org/project/what.html
Why give a Subject: line textbox that won't let me use all of it?
Because your browser is using a proportional font. Would you want the box to resize, triggering a reflow, every time you type a character? Even with the user-code performance improvements of the GCC 3.x series, the median user would still get lag.
Will I retire or break 10K?
No where does it say that a "real" i686 must have cmov, the compiler should check for cmov before using it.
The cmov instruction is used in tight loops. Would you really want to branch around cmov at run time based on the cpuid? It'd completely defeat the purpose of cmov. I say define "i686" as an ia-32 CPU with cmov and leave it at that.
Will I retire or break 10K?
There is something, it's called RHIDE. It's actually quite slick, I used to use it for programming apps using djgpp. I haven't used it in quite a while, but it looks like it's still quite active, with the latest release being Feb. of this year.
"Speed optimization has _never_ in my 5 years of using VC++ produced bad code..."
You make a fairly bold claim that the VC optimizer does not mangle code, especially after proving your limited experience. For a simple example go see the SMPEG mpeg decoder. The core audio decoding functions must be compiled with VC's global optimizations off or it will bork bork bork.
Vax users everywhere are crying. All eight of them.
Expert in software patents or patent law? Contribute to the ESP wiki!
Extfs use a one-minute granularity
Also false. Ext2fs uses has a one second granularity, like most traditional Unix filesystems. This is easily demostratable with "ls -l -time-style=full-iso". While this is still a fairly coarse measurement, I've never seen a problem in practice.
If you think it's easy, why don't you give it a try? [...] If you don't like it, you should demand your money back.
Now I understand why a friend of mine calls /. "too arrogant for its own good".
emacs can't print color on my bw laser printer!
I'm the one who filled the bug report, so I should
have known better.
I don't see why anyone would accept the current libc++ for anything else but a beta or even an alpha release.
It probably doesn't get noticed so much because fstream isn't used that much.
For something like koffice or kmail, assuming it uses fstream, I suspect that one would notice the difference.
The Intel compiler on Windows is about 30% faster than VC++ (version 6, we have not tried the .net version yet) with these same C++ programs, and the result is perhaps 4% faster than the GCC 2.9.6 Linux version (the program is entirely compute-bound, so this is not an OS difference). So far we have not seen even this 4% improvement in the Linux Intel compiler, which leads me to believe they have not put as much work into it as they did for the Windows one.
http://www.openmp.org/
With Dual CPU systems and Hyperthreading, you can get near 2X advantages on quite a few algorithms.
I haven't kept up with Gnu's OpenMP stuff. I guess this is one such project. http://savannah.nongnu.org/projects/gomp/
With gcc these days is it safe to compile my linux kernel and other stuff optimized for a particular cpu (eg: Athlon K7)? I read somewhere not to do this for the kernel? Grunt, we wants! :-)
... is find something Better Than Ezra.
Okay, it's a groaner.
I do development work using gcc on my local Mandrake machine with 3.2. I tried to compile one of my projects on our server which uses gcc 2.96 and it fails (3.2 follows the ANSI C++ standard, 2.96 is old-style) due to the older C++ libs. I want to upgrade our server to gcc 3.2, but since we've got other projects that work fine under 2.96, we are afraid of breaking the other projects (especially since we are close to release). Does anyone know of any gotchas? Can I just download, compile, and install 3.3 (or 3.2)? Will I also need to download, compile and install a new glibc? Can I install gcc 3.3 and not change my glibc version? Thanks, - Steve
I am reminded of a document describing how compilers are like women and assemblers like men. Googled for it, but didn't find it.
The line I remembered was "things you've been doing for years that seemed OK are now suddenly wrong." I consider myself a pretty astute programmer, but every new compiler version seem to have some new warning to add.
As a result, I consider my relationship with my compiler no less volatile than that with my wife. Keeps me on my toes anyway.
-HopeOS
I've seen numbers anywhere from 5%-200% penalty, though I don't have any references at the moment. It really depends on the app and where your main execution time lies. If you do a lot of tight loops over arrays, it's going to give you a significant performance hit. If you don't, it won't. So it's probably going to slow down your MP3 encoder a lot, but probably won't result in a noticeable slowdown for most userland apps. For most apps, which are I/O- rather than CPU-bound anyway, it's a good idea for security reasons. Same reason strncpy() is recommended over strcpy(), despite the performance hit due to bounds checking (in fact, strncpy() is just a special-case example of bounds checking).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Ack. I should have qualified it. I meant the earlier VS compilers. I have heard that VS.NET 2003 is quite complient.
A deep unwavering belief is a sure sign you're missing something...
Well, it bootstraps with -march=pentium4, and glibc compiles and runs fine with it, so P4 support certainly has improved. Exactly how good is it? If only I had a P4 to tell...
I heard a rumour somewhere that if ICC detects an AMD CPU, it either compiles the code to slower code (if it's compiling on an AMD CPU), or it builds EXE's that detect if it's running on an Intel or AMD and if running on an AMD, the EXE runs a bit slower. This was not true for early versions of ICC but at a certain version, they added this detection. Anyone know anything more about this?
The answer is however TRUE. As this is the make that comes with a certain development kit and is quite outdated.
-]Phreak Out[-
> Do Java and C# qualify as "VHLL" to you?
...
No.
A VHLL can be compiled, but it has to allow the programmer to take
certain things for granted, such as memory management. In a true
VHLL, it is not possible to dereference an invalid pointer, not
possible to overrun a buffer, not possible to jump to an invalid
address,
It is still possible to shoot yourself in the foot, of course,
but you have to do something visibly dangerous, like shell out
to a system call with untrusted data -- and compiler warnings
can alert you to all the places you do this, so you can check
them. You can mess up your checks, of course, or just not
bother to be careful, but it's better than a traditional HLL.
> Almost every user application except for cutting edge games
> could be written in Perl/tk or Python or XUL or something.
> Unfortunately, the ability to do this has existed for years
> if people aren't using it now I don't predict that they'll
> start.
They are starting; it's just gradual. Also, you (the user)
don't always _know_ an app is written in a VHLL. I didn't know
printerdrake was written in Perl until I needed to debug a
problem I was having. (The problem was not with printerdrake
as such, just a printer that wasn't supported, and I had the
manufacturer's PPD and was hoping to figure out how to make it
work.) I was able to trace the issue as far as foomatic, but
I ran into a binary (which was probably written in C) and gave
up then.
There's a performance penalty for using current versions of
Perl or Python instead of C. But hardware is getting better,
making that performance penalty less relevant, and the VHLLs
are getting better too. Perl6 is going to be *vastly* better
to work in than Perl5, for example. Personally, I would be
happy to trade 50% more CPU cycles and 50% more RAM for apps
developed in VHLLs, for an assortment of reasons, most notably
because such apps would be much easier to maintain.
It will come, in time. They said assembly language would never
pass out of vogue, because you got so much better performance
with it. Sure, it took longer to write programs, but you got
programs that performed better... C and its kin are basically
a case of that same thing.
What's odd is that lisp doesn't seem to be in this category
(with C I mean), even though it's quite old as HLLs go. I don't
think I'd consider common lisp to be a VHLL either, though. I'm
not sure where to categorise lisp.
Cut that out, or I will ship you to Norilsk in a box.
> If Linux really required all those extra developers for that much
> less net production
How do you calculate net production?
Cut that out, or I will ship you to Norilsk in a box.
> why is it that no programmer's editor cannot
> print the highlighting in color?
As everything else, Emacs does it just fine.
Hm.Let's say i has value 3. = has associativity right to left. So the expression on RHS should be evaluated first: i gets incremented, RHS gets value of 3. Then the LHS is evaluated to a[4]. Finally RHS is assigned to LHS: a[4] get's value of 3.
However my compilers disagree with each other. Can someone enlighten me?
Please read my post again, or find yourself an authoritative reference in C. In C, the order of evaluation is essentially undefined, except at sequence points, where all previous expressions and side effects are fully evaluated. Accessing and modifying an object separately between two sequence points is undefined behavior.
It has nothing to do with associativity, which only means anything if your C statement doesn't invoke undefined behavior.
However my compilers disagree with each other.
Not only that, your compiler may disagree with itself depending on whether optimizations are enabled or not. This is because you invoked undefined behavior, for which no particular result can be expected.
Actually, the last change was Technical Corrigendum 1 published in 2001. However, it was mostly minor defect fixes, so it's not really an excuse. I think they major reason the original parent is bitching is that he's used to Visual C++ 6.x, which just likes to pretend that the C++ standard hasn't changed since 1995 :)
A deep unwavering belief is a sure sign you're missing something...
The compile server was still experimental last I heard.
You need to reorganize your Make files to use pch's efficiently. You should
1) Not change any of your source or header files.
2) Add a new "all.h" header including all other headers, and precompile that header and only that header, whenever any other header changes.
3) all.h should not be included directly from any file, instead compile with a special flag that "pre-includes" all.h.
4) Because of header guards (which you must use), none of the normal header files will be included.
5) Because no file include all.h directly, it will not figure in the autmatic generated dependencies, and you should not add it manually. Thus, any source file will be recompiled only when the header files it includes directly are changed.
This solves the "only one include file" problem AC mentions, and means the source and include files are identical to the non-PCH version.
The danger is that there might creep in hidden dependencies, i.e. source files that does not include all the headers they should, yet compile due to the pre-include of all.h. So you will have to make an occational build without PCH.
I'm not counting TC1 as part of the language until the public actually has access to it (for a fee or otherwise). It's still only available to committee members at present.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
In fairness, I should point out that I don't know how to do most of this either. But I don't complain about volunteer work not living up to my expectations...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
With comments like this, I'm surprised it compiles at all. Please find some non-hacked together code to put me on trial by.
"Added a hack to seek past raw video data in a system stream"
-]Phreak Out[-