Slashdot Mirror
GCC Compiler Finally Supplanted by PCC?
Sunnz writes "The leaner, lighter, faster, and most importantly, BSD Licensed, Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc. The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. Even though much of the compiler has been rewritten, some of the basics still remain. It is currently not bug-free, but it compiles on x86 platform, and work is being done on it to take on GCC's job."
I notice that TFS doesn't say that anyone is actually able to compile anything (other than PCC) with it. The BSD folks would love to have a BSD-licensed drop-in replacement for GCC; but it doesn't sound like this is it. Not yet at least.
./build.sh or whatever).
Wake me up when you're able to use PCC instead of GCC to do a 'make world' (or
Kind of depends on who you ask, doesn't it?
OK, so it compiles C on x86. What do I use when I want to compile objective C on my microwave?
For commercial software, pointing to the GCC source isn't that much of a burden if you need to distribute a compiler.
I'd have though the fact a compiler was faster and or lighter would be much more important than the license it uses. Why is that not the case?
Someone please elaborate. What makes this C compiler better than the one in GCC? (I am not asking about licensing issues)
Someone relicense it under the GPL!
"NetBSD's" pkgsrc is really everyone's pkgsrc. Try it on what you're running right now.
It's my primary package manager on Interix, Mac OS X, Linux, and NetBSD.
Not a replacement for GCC anytime soon. I'm not sure why there was a need for a compiler licensed for BSD, but it's always nice to see options being developed for anything.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
GCC Compiler Finally Supplanted by PCC?
No. Next question.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
I really don't see any point in implementing a new C compiler under the BSD lisence. There's no reason to duplicate effort: it's not like the compiled binaries would be under the GPL. And any GPL libraries you link to, you wouldn't need to distribute (thus avoiding the GPL). So, really, there's no point in duplicating effort on a BSD lisenced compiler. Correct me if I'm wrong.
Seriously. Let's duplicate the wheel twice: once for GPL, once for BSD, and then bicker amongst ourselves. Stuff like this stands in the way of actual progress being made. Neither side is right, I don't have a solution, but this is just dumb.
twitter.com/gravitronic
call me when pcc does something useful, like, say, working.
Nope.
a) This new version of PCC is nowhere near production quality.
b) NetBSD != Linux
Not really; you already have the sun and intel compilers for Linux (I've been told that the intel compiler has even been tweaked so you can build a bzImage with it).
But you're still stuck with using glibc if you want to be able to compile anything. You do have different libcs floating around, uclibc, etc; but they're all gnu and they're all meant for embedded market. I doubt you'd be able to recompile the linux kernel with any of them.
I think of it as if it shall be able to compile and run on PDP11 (even if it may not happen in reality).
Like I don't have enough things to spend my time on. Maybe I should finish my PDP11 page first.
--- Often in error; never in doubt!
# cat
Damn, my RAM is full of llamas.
pcc will take YEARS to get the functionality and optimizations that gcc has. Even if it compiles slowly and sometimes generates dumb code.
Either way, they'd much, much better off if they imported LLVM and redirected their compiler brain power to clang.
Well, that's fairly pointless that it only compiles x86 code. So, it basically means they're competing to make a compiler which is BSD licensed and compiles the most common processor out there, against the biggest GPL licensed compiler on the most common processor?
I really think some effort needs to be put in to support other processors like ARM, MIPS and PPC - after all, GCC is a hardly a diva for any of these (code generation is terrible) and they are not the fastest platforms either. This is where actual performance improvements and quality code generation would actually count for something.
PCC is interesting, but it's based on technology from the 70's, doesn't support a lot of interesting architectures, and has no optimizer to speak of.
If you're interested in advanced compiler technology, check out LLVM, which is an ground up redesign of an optimizer and retargettable code generator. LLVM supports interprocedural cross-file optimizations, can be used for jit compilation (or not, at your choice) and has many other capabilities. The LLVM optimizer/code generator can already beat the performance of GCC compiled code in many cases, sometimes substantially.
For front-ends, LLVM supports two major ones for C family of languages: 1) llvm-gcc, which uses the GCC front-end to compile C/C++/ObjC code. This gives LLVM full compatibility with a broad range of crazy GNU extensions as well as full support for C++ and ObjC. 2) clang, which is a ground-up rewrite of a C/ObjC frontend (C++ will come later) that provides many advantages over GCC, including dramatically faster compilation and better warning/error information.
While LLVM is technologically ahead of both PCC and GCC, the biggest thing it has going is both size of community and the commercial contributors that are sponsoring work on the project.
-Chris
It seems profoundly stupid to stress out the BSD license as the "most important" feature of this new software.
GPL may not be as free as BSD-license, but one needs to be a real zealot to switch based primarily on this reason. I hope, FreeBSD will wait for it to work on other platforms and only switch because it is "leaner, lighter, and faster".
In Soviet Washington the swamp drains you.
"So, really, there's no point in duplicating effort on a BSD lisenced compiler. Correct me if I'm wrong."
From the discussion of TFA:
The licence is just the top of the iceberg
Can't you just check in at slashdot here and there? If you post a number, I suppose I can try to remember, but geez....
Let me get this straight. A compiler that has been production-quality for over 15 years, compiles everything on every architecture, and has been continuously improved every minute of its existence needs to be replaced by ... Son of pcc? Because of a license?
Sure, I prefer BSD-style licenses, and so do some other people, but what drives gcc development is the GNU license. I think I'll stick to the compiler that's debugged. Oh, that's right, I forgot, it comes with a debugger too. If you like that sort of thing.
I'd say "no." Here's why:
I took it to mean that it compiles code 5-10 times faster, but that compiled code itself is usually slower. Not having many optimizations explains both of those "features".
Ben Hocking
Need a professional organizer?
Someone got pissed during the recent license flap when taunted with "yeah, if BSD is so great, why do you all use gcc?" or something like that. So they're trying to send the message to the GPL types that "we don't need you any more."
At least, that's my take on it.
Honestly, BSD vs. GPL has always struck me as one of the stupidest flame wars. It's like that phony debate between "great taste" and "more filling" only people take it seriously.
Personally, I'll license my own software under whichever I feel more appropriate for the task (and that could be either) and tell anyone who complains about it that they can go screw themselves with a rusty chainsaw.
http://gsoc.cat-v.org/projects/kencc/
How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.
Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.
Man page
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
FSF's increasingly extremist political views
FSF's views have not changed over the years - they have remained consistent.
The reason they look "increasingly extremist" is because of other views on software freedom heading the other way, thus drawing an even greater contrast. That does not mean that the FSF views are the ones that are extreme...
If anything the FSF and RMS have shown themselves to be quite prescient in warning against dangers that have come to pass.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
...can you elaborate on your "experience" from which you have concluded that crashes in current Linux apps are due to GCC?...Did you read my submission...or are you engaged in what I call syntax distortion? I did not say "...crashes are due to GCC...", what I said is that crashes are in large part due to GCC.
It would be helpful if you too, provided evidence to back up what you are saying. Watch this threade.
Really why not if they want to.
Maybe they thing they have a better idea.
Maybe the don't want to work under the FSF and the GPL.
It could be that they really don't like the direction that GPL is going. Sure right now programs compiled under the GCC don't have to be released under the GPL but when GPL V4 comes out that might change.
Or maybe they just don't want RMS to start ranting about how they should call BSD GNUBSD since the kernel and the user space programs are only part of an OS. It takes a compiler and things like KDE and GNOME to make a usable OS and given that without those GPL programs there couldn't be BSD the BSD should give GNU it's fair share of the credit.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Even if a compiler generates miserably inefficient code, it is valuable if the code is correct. It ia a valuable tool to use for the verification of other compilers. It can also be used as part of a compiler bootstrapping process. Since its code size is probably a small fraction of GCC's, it may make a better teaching tool. If people are actually going to use it, given that it must coexist in a world with much more mature compilers, it will itself probably become much more mature in a relatively short period of time. GCC currently has no competitors in the free realm and has suffered from neglect in the past. A little competition may keep the developers on their toes and prevent another egcs.
Just how lean, light and fast does a C compiler have to be?
Surely, even the largest C projects compile in tolerable times on entry-level hardware these days.
I, for one, miss those long lunch-hours when I could call out "Another Martini, Barman! - I can do nothing until the operators page me!".
GCC has been continuously changed not continuously improved. With each new chip that it optimizes for it seems to drop support for an older one. Plus it is dog slow.
Johnson family of products. We will WAX GCC...
(Sorry, Johnson & Johnson popped into my mind as soon as I read that...hehehe). Too much Saturday AM TV in the 70's and 80's for me, I guess....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
I was seriously thinking last night... "what the world needs is another compiler".
It would have been nice to know what the non-licensing aspects of the pcc were, there are already a number of BSD licensed compilers. It is interesting in one of the posts about pcc someone goes on about how the evaluation of x = y changed in 3.x to 4.x of gcc and they were told "suck eggs" by the gcc team. What i dont get about that whole comment is how they think that's going to change with pcc. The original problem still exists - the c standard is unclear (but thats off the point a bit).
It would be nice to see the effort perhaps pumped into something a little more worthwhile. But, rebuilding the wheel is anyone's prerogative, and as long as it makes you happy and perhaps solves a problem for someone, more power to ya! Compilers seemed to have become a bit of a topic of late which is interesting considering how over the last couple of years people have been working hard to abstract away from the actual compiler.
Please. I think RMS would prefer, GNU/NetBSD != GNU/Linux. Obey the beard!
Unless you have looked at some core dumps, then your "experience" is not worth very much. I haven't seen any problems with generated code with GCC since 1996. Sometimes it doesn't compile the latest and greatest C++, but it's never generated incorrect code for me.
"It doesn't cost enough, and it makes too much sense."
There is always the Intel compiler ...
Desperate to get off topic, huh?
Having a better compiler is nice, but doing it just because you don't like the the open source license attached to the compiler - not the code it generates, just the compiler - just seems petty and a waste of effort.
It's just stupid all of the effort being wasted on the feud between BSD and GPL. The energy should be used to have all software released as open software, and then, interestingly, there would be no need for the GPL.
TenDRA is another compiler the BSD people have been looking at for quite some time as well.
“Common sense is not so common.” — Voltaire
Translation:
Yes, I am a troll.
Unless you consider 0.01% to be a "large part", h890231398021's response is valid.
I used to use the old PCC on all sorts of weird mini-computers in the '80s. I wonder if it still spits out a "too many shapes" error when functions get too big?
...
At the time people were wondering if GCC would ever be good enough to replace it
A lot of people don't realize it was relicensed as BSD and have been overlooking it. Good catch!
Plan9 has some C compilers too that are under a very liberal license, but they are really a subset of C designed for building Plan9 components.
“Common sense is not so common.” — Voltaire
In theory, it should. It's smaller, which is why it's so attractive to the OpenBSD folks. They want a simple compiler that produces correct code, and PCC seems, at first glance, to meet their needs.
I am TheRaven on Soylent News
You might wanna RTFA before giving us your great insights... One of the main points the OpenBSD folks are interested in it is because they can easily port it over to architectures that GCC has dropped, that the OpenBSD folks still use.
You have a 0% chance of finding a bug in the compiler in anything you're coding. That's not to say there aren't any -- the company I work for finds compiler bugs every once in a while. We're also compiling libraries for system-level stuff on pretty much every platform we can get our hands on. If you're just doing applications or even academic stuff, you're not going to find a bug in gcc.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Perhaps the fact that it generates assembler output (a.out) rather than the later and now more widely used Executable and Linkable Format (ELF) binaries?
Resistance is futile. Reactance buggers it up.
The biggest reason for the new compiler (despite the jackass article submitter's position) is that GCC does *NOT* support every architecture. GCC drops architectures frequently as the core contributors lose interest, which hurts OSes like NetBSD that try to support more than the mainstream architectures. NetBSD relies on a combination of GCC 2, 3, and 4 to compile the OS on all of the architectures it supports.
The idea with PCC is not that it will be BSD licensed (nobody really gives a fuck what license the compiler is under), but that it will be supported directly by the BSD community, including the NetBSD hackers who have their bazillion architectures to support.
It took three weeks for one person to write the x86 back end. That is one of the reasons OpenBSD is interested in it; it should be easy to add support for the platforms GCC has dropped.
I am TheRaven on Soylent News
s/[i][/i]/
My bicyles
First: PCC has not YET supplanted GCC. The BSDs are hoping it will in the future.
Second: The biggest attraction of PCC is NOT the license. The article submitter who stated otherwise is a jackass.
Third: There are techical reasons why GCC is actaully unusable by some BSDs, such as NetBSD, which aims to support many architectures that GCC has dropped. NetBSD uses a combination of GCC 2, 3, and 4 to compile all of its different architectures. The NetBSD developers would rather have a single compiler that handles them all. Obviously PCC is nowhere near that level yet, of course.
Fourth: GCC politics are a pain in the ass for many BSD developers who just want to submit patches to a compiler without the overhead of GNU's policies and GCC's management.
Fifth: GCC produces crappy code more often than anyone would like. GCC bugs are far from unheard of, performance of generated code is often unpredictable between releases, and in many less commonly used architectures or sources GCC will produce incorrect code. Yes, these cases are very rare, but the BSD folks have hit the problem often enough for it to be a concern. PCC, being simpler and less bloated with cruft from multiple rewrites of the internals will hopefully produce correct and predictable code more often than GCC.
Sixth: PCC actually works today. It can compile most of the NetBSD userspace, as I recall, and the kernel will be ready to roll soon after some inline assembler problems are fixed. This isn't some theoretical hacky project - it works right now. It's not ready to replace GCC just yet, by any means, but it's a lot more than some Slashdotters seem to think it is.
But you're still stuck with using glibc if you want to be able to compile anything. You do have different libcs floating around, uclibc, etc; but they're all gnu and they're all meant for embedded market. I doubt you'd be able to recompile the linux kernel with any of them. No no no. Repeat after me: "GNU != GPL" "GNU != GPL" "GNU != GPL" "GNU != GPL". You can use the GPL license (yes, even the latest GPLv3) without accepting any oversight or political interference by the Free Software Foundation / GNU project. Just ask Linus Torvalds. He freely admits that choosing GPLv2 for Linux was the best choice he ever made, but the Linux project is not controlled by the FSF in any way, and in fact Linus disagrees with them on nearly all current issues of software politics
My bicyles
I don't think anyone's actually using GNU/NetBSD.
I am TheRaven on Soylent News
I haven't read TFA yet (plan to ASAP), but I wanted to mention that PCC isn't the only show in town.
TenDRA is a mature, BSD licenced compiler originally developed by the Defence Evaluation and Research Agency (DERA) in the UK. Not sure about pkgsrc, but TenDRA is in FreeBSD's ports.
As for converting an entire operating system over to a non-gcc compiler... well, it's complicated. TenDRA is useful for sanity checking but currently cannot build the FreeBSD kernel, nor even the world. Intel's proprietary icc compiler, on the other hand, can build world just fine (kernel, not so much). Forget about using icc though, if you're a commercial customer ($$$) or if you have a gnu up your butt about free software.
I'd be interested to see how PCC compares vs. TenDRA.
while the person you're responding to *is* a troll, I guess it's worth pointing out that GCC and other highly optimizing compilers will "break" some apps that a simpler compiler won't break. Why?
Many optimizations rely on careful reading of the standard, and explicitly taking the liberties that the standard lets you take. For instance, the following loop terminates on a simple compiler, but becomes infinite on some optimizing compilers:
int i = 1;
while (i > 0)
. . . i = i * 2;
The ANSI C standard states specifically that signed integer overflow behavior is implementation defined. If you were expecting 'i' to go negative after 30 iterations, and for that to terminate the loop, you could be in for a nasty surprise.
Suppose an application relied on this behavior, and now it misbehaves when compiled with GCC. Did GCC "break" that application? In some sense, yes: The app functions correctly with compiler (a) but not with compiler (b), so the app must be compiled with compiler (a). The breakage, however, happened because the application its not strictly conforming. It uses compiler dependent semantics, and that's hardly GCC's fault.
Simpler compilers also don't reorder code as much, and don't optimize away as much "dead code." Stuff that really should have memory barriers, explicit synchronization and perhaps the volatile keyword applied to them run just fine without all those things when compiled with a simple compiler and run on a scalar, in-order CPU. The source code is also easier to read, because in the end the semantics are much more restricted--meaning the compiled output more closely resembles the source input. Give that code to a highly optimizing compiler, though, and run it on a super-scalar, out-of-order machine, and it'll break left, right and center. Is it the compiler's fault? Is it the CPU's fault? It's really the gap between the semantics the programmer thought he had (and happened to have in the simpler environment), and what C actually guarantees.
Simpler compilers implement simpler semantics that are easier to understand, but only because they're compiling a very restricted form of C that offers way more implicit guarantees than the C standard actually does. Personally, unless that's made explicit (and therefore truly guaranteed forevermore by the compiler), I suspect it's actually a recipe for disaster. If nothing else, it could lead to code that's significantly harder to move to different platforms, since it'll start to rely on these simpler, "easier" semantics. Of course, then again, super-scalar out-of-order CPUs still strip a bunch of that away, so who knows, it might not be that bad.
--JoeProgram Intellivision!
Neither is GCC.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
the floor wax guy?
...the future crusty old bastards are already drinking the Kool-Aid.
Well, playing devil's advocate, because it could insert malicious backdoor code into your program. Obviously, this is not a concern with a BSD license, but I'm just looking at worst-case scenario. A good reverse compiler would probably make that obvious, but ideally at least that would be open-source.
Ben Hocking
Need a professional organizer?
Seriously, if you're writing code for a living, especially performance-critical code, isn't hardware/platform optimization for the end-use binary far more important than speed of compilation? Particularly if that binary gets blown out to hundreds or (of?) thousands of boxes. If I had to choose between a slow, but hand-tuned GCC for my platform or a quick other compiler that made correct but mediocre-performing (no SSE?/3DNow/VMX/VIS or whatever) binary code, I'd say GCC no contest.
And frankly, slower compilers mean secksier hardware requirements for workstations.. ("Yes, GCC4 is slow, that's why I need that dual quad-core Xeon with 4GB RAM!!")
Meh.
ELF has a wide set of problems as well, especially on 64-bit.
ACK 6.0 has ELF support on some architectures. It's pretty trivial to add support for other binary formats if you wish, maybe some COFF and PE support?
Now what ACK does not have is something like GNU binutils. But few compiler kits have anything like that.
“Common sense is not so common.” — Voltaire
Maybe LLMV (http://llvm.org) will be of interest to OpenBSD folks.
Highly BSD compatible. Advanced.
True-Freedom BSD-Style License (no Communistic-License like GPL).
http://llvm.org/releases/1.3/LICENSE.TXT
While LLVM is currently being developed using GCC it's intended to stand alone at some point.
From the LLVM web site: http://llvm.org./
Low Level Virtual Machine (LLVM) is:
1.
A compilation strategy designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time and offline (i.e., after software is installed), while remaining transparent to developers and maintaining compatibility with existing build scripts.
2.
A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands. This combination enables sophisticated transformations on object code, while remaining light-weight enough to be attached to the executable. This combination is key to allowing link-time, run-time, and offline transformations.
3.
A compiler infrastructure - LLVM is also a collection of source code that implements the language and compilation strategy. The primary components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework with a growing set of global and interprocedural analyses and transformations, static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors.
4.
LLVM does not imply things that you would expect from a high-level virtual machine. It does not require garbage collection or run-time code generation (In fact, LLVM makes a great static compiler!). Note that optional LLVM components can be used to build high-level virtual machines and other systems that need these services.
LLVM is a robust system, particularly well suited for developing new mid-level language-independent analyses and optimizations of all sorts, including those that require extensive interprocedural analysis. LLVM is also a great target for front-end development for conventional or research programming languages, including those which require compile-time, link-time, or run-time optimization for effective implementation, proper tail calls or garbage collection. We have an incomplete list of projects which have used LLVM for various purposes, showing that you can get up-and-running quickly with LLVM, giving time to do interesting things, even if you only have a semester in a University course. We also have a list of ideas for projects in LLVM.
LLVM was started by the Lifelong Code Optimization Project, led by Vikram Adve at the University of Illinois, Urbana-Champaign. Since the first public release, LLVM has grown to include contributions from several other people! We welcome external contributions, so please send e-mail to llvmdev@cs.uiuc.edu if you are interested in contributing code to the LLVM infrastructure.
Why would you want Linux without GNU? Since you seem to prefer the BSD user land, why not just use a BSD kernel? What does linux do for you that BSD doesn't?
Give me Classic Slashdot or give me death!
That seems dumb. They should talk to the LLVM guys about getting it licensed under BSD or the like. IIRC, they state on their webpage that they're open to discussing other licenses, and LLVM totally kicks ass. Someone does need to write a native C and C++ frontend for it though. It currently relies on GCC's frontends.
There's tcc, lcc and bcc. tcc also compiles the Linux kernel, or so I heard, but the resulting binaries aren't as fast as gcc's. Does it do c++, like the GNU compiler suite, and java and fortran too ?
Religion is what happens when nature strikes and groupthink goes wrong.
It might be of no interest to you, but im running "linux environment" on a machine that likely has less RAM than your core 2 duo cache. I dont compile applications for it with GCC, because its code output for ARM is just bloat, and its accompanying GLIBC is bloat squared.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Good luck. The C99 Standard weighs in at 554 pages - about on par with the Fortran 2003 Standard (580 pages). Writing a small compiler for a large language spec will be no mean feat.
Insightful, not funny! Well, a bit of both. But this truly is a lesson the entire software industry needs to learn. Where are my mod points when I need them...
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Sure, the license is nice, but PCC compiles NetBSD's userland five to ten times faster than GCC. If it was only a few percent worse on code generation, it would save vast amounts of time for developers trying to work on large code bases.
GCC is a pig. The point of resurrecting PCC is that it is not a pig.
When I think of "hot air", I'm more likely to think of posts that make no substantive argument and engage in name calling ("retarded") rather than the work of someone who has written a lot of software, started a social movement for securing software freedoms, and asks for a fair share of credit when people mention the name of a project where the initial author is quite derisive about said freedoms.
I can't agree with your overmoderated post. I think you would benefit from reading the GNU/Linux naming FAQ which addresses your concern about why people ask others to refer to the union of the GNU OS and the Linux kernel as "GNU/Linux" or "GNU+Linux".
Digital Citizen
Yeah, sure I will believe that when I see it.
gcc isn't just a compiler it is an entire philosophy based on supporting computing language grammar.
If you just want a C compiler then perhaps it isn't what you need.
But if you want:
1) Cross platform support of a variety of computer grammars.
2) Very simple, highly modular architecture to facilitate building extensions and finding bugs.
3) The most sophisticated support tools for debugging and optimization of code.
4) A much better license that fosters community contribution and growth without cost.
5) Multi-threaded huge compilation capabilities with tools to do clustered compilations of massive code trees.
6) CPU independant code generation and optimization capabilities.
7) GCC is tried and true and has compiled more code than any compiler EVER has. Beat those stats.
[....list too long due to the limited storage capacity of Slashdot servers.]
With respect to 4, unlike a BSD based license which encourages corporate theft of everyones hard work might I add.
What they are saying is simply impossible.
pcc cannot take over gcc's job because if it did it would be just as large and have the exact same problems as gcc.
One of gcc's job's is to turn C code into binary form, which sure, then maybe.
But gcc does way way WAY too many things to simply be replaced outright by this little C "and thats it" compiler.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
The user-visible portions of userland (X11 and the window manager) are not GNU projects. If a program does not have the magic words `Copyright xxxx Free Software Foundation' at the top of every source file, it is not a GNU project.
The vital portions of userland that are GNU projects are gcc and glibc. Not all Linux systems use glibc, particularly in the embedded world. With a viable non-GNU C & C++ compiler and a full-featured libc, a GNU-less/Linux is most possible.
I, for one, do not believe that glibc (or gcc+glibc) being GNU projects justifies renaming the architecture. For a long time, HJ Lu maintained a forked libc for Linux.
Then the answer is no. I may be alone in the world but I'm perfectly happy with the gcc compiler and have been for years. It does what its supposed to, It is FREE, It is crossplatform (MingW), and it annoys the BSD guys.
Clear Winner. GCC
It has been pointed out here, that people who choose a compiler based on its license are idiots. Well if I'm working on windows I use MingW specifically because of its license. If I'm working in Linux and I usually am, I choose GPL above all others. Count me as an Idiot if you like, But you can shove the alternatives. I know what I am getting and have a reasonable expectation what is coming in the future, and if I need to modify it (Heaven Forbid) I can. BSD is a fine license for people who NEED it. I don't. When given the choice I choose GPL. GCC Slower, maybe so. Code works and I get paid. If it takes 3 hrs for QT to compile. I bill for 3Hrs.
Sorry but, I'm a pragmatist in all things except freedom. I've been burned enough. (Admittedly, I've personally never been burned by BSD code, unless you count Windows.)
OSGGFG - Open Source Gamers Guide to Free Games
Wake me up when you're able to use PCC instead of GCC to do a 'make world'
I'm surprised nobody's mentioned tcc on this thread - it's lighter, faster, and close to a drop-in replacement for x86. The original poster doesn't seem aware of the wider context or they might have mentioned icc too. Even lcc is almost a drop-in, if far less optimising than gcc, and it supports more than just x86 targets.
you had me at #!
You're right. This is the same thinking that brought us OpenRCS...
And what does GNOME run on? The GNU Windowing system?
Ok, we can ignore tar/grep for most desktop users. We can ignore gcc/make/etc, as they are development tools -- not relevant to anyone but developers. (After all, I'll bet Doom 3 for Linux was built with GCC, but we hardly call it "GNU/Doom3", now, do we?)
No one calling it "Linux" wants to discredit the GNU people, but frankly, I'm glad we don't have to acknowledge every little contributor in the name. I run an operating system which I call "Kubuntu", and occasionally "Linux" so people have something to refer to. I use KDE, some GNU utilities, some Perl and various other things not even GPL'd, and some things I'm not sure are entirely legal, like libdvdcss.
GNU is pervasive in my system -- but no more pervasive than any other random element, like X.org.
Don't thank God, thank a doctor!
Think about it. Getting a new compiler into free UNIX and the open source community is going to be as hard as getting a new platform on the desktop to compete with Windows. And for similar reasons.
You're not going to supplant GCC until you get all the code that depends on GCC-specific features modified to be standard portable C. That's a barrier to entry as steep as Microsoft's application barrier to entry. Now it's not as bad as it was in the early '90s when GCC was sprouting new C extensions everywhere (like the ability to have declarations not at the start of blocks, or the ability to leave the second element out of the trinary conditional operator, or things like alloca), and a lot of those features have now become common and even standardized (and others, like the shortcut trinary, have been deprecated). But it's not as easy as just having a good compiler, or even a good language translating ecosystem like Tendra... the playing field is anything but level.
They say it builds the tree much faster - I can believe that - but does the code run faster?
Could you back up #3 with some quotes?
In any case, let me introduce position #4: The system I run today has all kinds of elements in it, from all kinds of projects, open and closed. GNU is one of them, along with KDE, QT, X.org, Perl, Apache, PostgreSQL, the Ubuntu/Kubuntu projects... Hell, the next version of KHTML (Konqueror's rendering engine) will be incorportaing code from Apple, for fuck's sake!
To be completely fair to all parties, I'd have to call it: GNU/TrollTech/KDE/X.org/Perl/Apache/Postgres/Ubuntu/Kubuntu/iLinux.
Oh wait! I forgot the hardware manufacturers! What was I thinking? I guess I better add an AMD/nVidia/BioStar/KOSS/SysKonnect/Realtek/Creative/Sceptre/Logitech to the mix.
Starting to get the idea?
Frankly, I'd rather call it whatever I want and deal with RMS complaining, than have to read the entire list of contributors every time someone asks me what OS I run. So I call it Linux, KDE, Ubuntu, and Kubuntu. The GNU project has plenty of visibility -- I see it every time I look up the docs for a tool I'm using (GNU Make, Gnu C Compiler, etc), not to mention the occasional time I fire up the Gimp.
Don't thank God, thank a doctor!
According to Wikipedia, a modified version of lcc was used for compiling Quake III. It seems to me, this compiler would be far more maintainable, but for some reason, the world doesn't seem ready for literate programming.
"There's no reason to duplicate effort:"
Developers are people, they cant be moved around like currency.
Scratch an itch: People program from inspiration and/or motivation, if this is how these developers are willing to donate their time to the community
who are we to say they should try and do something else.
The free software community is not a monoculture, competition amoungst projects can lead to higher quality software for all those competing.
You might call that a quality of implementation issue. :-)
That said, my point still stands, and in fact is bolstered: Just because the C standard leaves it undefined doesn't stop compiler writers from giving the situation a useful definition. The resulting language is a superset of C, though, and is thus compiler specific. A program which relies on this variant of C is non-conforming.
I guess the beef here is that "implementation defined" means a program could be conforming but not strictly conforming if it relied on implementation defined behavior, eh?
--JoeProgram Intellivision!
There's no logic to supprot "Linux" as a name, and there's actually relatively little logic to support a desktop environment or a distro as a name.
At least if we're talking about who should be credited in the name, the logical answer really comes down to this: Everyone has an equal claim. However, you don't see X.org throwing fits and refusing talks or interviews with people who refuse to call it X.org/Linux, even though X.org is arguably as much code and as much a necessity of a modern Linux desktop as the GNU tools are.
(Yes, X.org probably requires gcc and glibc. However, no one would care enough to continue developing either if they had to do so without a GUI.)
Actually, there is one very, very good reason for using "Linux" as a name: It tells you what's compatible. A clueless person who buys, say, UT2004 or Quake 4, knows that it's compiled to run on a Linux kernel. Most of the other things aren't as relevant -- X.org just happens to be the best X server, but it could theoretically run under something else. Ubuntu is slightly more relevant, but these games are proof that you can distribute a distro-neutral binary.
As far as many applications are concerned, Linux is the operating system, the rest are just applications. Yes, some of them are required, but this is also the case on Windows -- sometimes you need a particular video codec installed, for example, to play pre-rendered cinematics in a game. The codec might be part of Windows Media Player, but isn't part of Windows. There are also things like Steam -- you need Steam installed to play Half-Life 2, but we don't consider Steam to be part of the operating system.
So, when you get right down to it, I would call Linux the OS, and a particular distro would be like a version or "flavor" of other OSes (like XP vs Vista, or Ultimate vs Home Basic). Not out of any logic for who should get credit, but because it tells customers what they need to know about application support and customer support, which are really the only two places the customer would care about the specific OS they're running.
Don't thank God, thank a doctor!
1. Is is C++0x ready?
2. Does it work with FreeGLUT or MESA for OpenGL support?
3. Can it make ice cream?
The Rapture is NOT an exit strategy.
in terms of providing ways of verifying, at least *type* correctness.
In terms of verifying the correctness of the implementation of an algorithm... you have to accept that is a practice that will never exist outside of academia.
That's not to say we should never prove things about algorithms, but rigorous proofs should not be done on production code and on production languages. Use psuedocode if you want a proof. Correctness of algorithms in production code comes from the fact that those algorithms are 1. derived from well known and proven algorithms, 2. are "obviously" correct, 3. have unit tests to provide *empirical evidence* for the correctness of their implementation.
Real companies put more emphasis on empirical evidence of program correctness, especially unit tests, than analytical solutions. Type correctness is a powerful tool, but aside from that it's pretty much impossible to determine program correctness while still allowing for efficient low level programming constructs that are necessary in production code.
If you go back to the old gnu newsletters there is the bald announcement along the lines that gnu needs more attention and it is a good thing that it can get it if everyone is aware that there is gnu in their linux distribution. Personally I didn't agree with it when the silly LiGnuX name was suggested and then when it was revived as the gnu prefix. The water got muddied a bit more when there was the insistance by people that should know better that linux was the kernel of the gnu operating system and this line was swallowed whole by newbies that really should look up a textbook. The whole thing is annoying to those of us that remember the response RMS used to give to any question asked about linux some time ago "Linux? Never heard of it - haha". Going from that bad joke to implied ownership in under a year is what I consider bad form even if you think it is for a good cause.
You mean the sentence that says "This product includes software developed or owned by Caldera International, Inc." (emphasis mine)?
If that's "Caldera before SCO", it says nothing about whether PCC was "developed by SCO". If that's "Caldera after SCO", the question is whether it's "developed by" or "owned by"; if it refers to PCC being part of the UNIX source code base, well, that's "developed by AT&T, owned by SCO", not "developed by SCO" (which PCC wasn't, although SCO might have done some work on their version of it, just as they presumably did work on other parts of the UNIX they originally licensed from, and ultimately bought from, AT&T/USL/Novell).
Just because you compile with GCC doesn't make your system a GNU system. Otherwise, the Game Boy Advance system would be the GNU/GBA, as Nintendo provided a port of GCC as part of the GBA SDK. (Homebrew developers use a different port of GCC.)
If I had to make a guess as to what deserves a GNU/ prefix, it would have something to do with the userland, which executes even when nothing is being compiled. As far as I can tell, only Linux uses glibc and GNU Coreutils out of the box. FreeBSD has BSD libc and BSD Coreutils.
Ken Thompson
Link
You are being MICROattacked, from various angles, in a SOFT manner.
Wake me up when it supports C++0x.
Until then PCC will be a toy...
Cheers
Ben
The Electric Railway Association Presidents Conference Commission was set up in 1933 to develop a streetcar that would better meet the competition from cars and buses. The resulting design was produced in the US from 1936 to 1952.For the non-streetcar fans, PCC = Portable C Compiler.
A Shadeless room is a brighter room.
When did Linux come into play? The summary only stated [Open,Net]BSD.
But, since you asked, diversity == good.
The license doesn't explicitly say you can't modify it because it goes without saying that you are not allowed to modify it. If the default was for licenses to be freely modifyable by recipients then they would all be worthless. Also, it would be asinine for the default to be that you can freely modify the license because then every single license would have to have a standard clause that says you can't modify it.
The same rule applies to copyright notices. You are not allowed to modify the copyright notice on a work even though it doesn't explicitly say such modifications are forbidden. The BSD license reminds recipients that they have to keep the copyright intact, but this is done as a courtesy and is not required.
As for your Wikipedia quote, I already gave a detailed explanation of how BSD licensed code can be distributed along with code that has a more restrictive license because this might be what has caused the widespread misunderstanding that you are still suffering from.
The rule is trivially simple: unless you are given explicit permission from the original author, you can't change the license or copyright notice on someone else's work. Period.
We don't see the world as it is, we see it as we are.
-- Anais Nin
Undefined behaviour? What's wrong with that? Do you really want to standardise, say, what happens when you reference a dangling pointer? That would require every pointer access to be wrapped in checking code, with metadata stored with every pointer, introducing a massive overhead on the lowest level operations. C is low-level. If you don't want a low-level language, then don't use C.
Every usable OS, maybe, although I could probably find some niche OS written in Java or something.
Oh, and they aren't all written in C. I'm not sure if Windows is entirely C, or some combination of C/C++, and the same may be true of OS X, sort of (it'd be objective C). But honestly, any modern OS is also going to need significant chunks written in assembly. If you're going to have to do some low-level stuff and some high-level stuff, why not use C/asm only where needed, and use another language for the rest of the system?
But never mind. I shouldn't argue too hard, mostly because while I'm convinced a good, entirely non-C OS can be written, even without memory segmentation (see Microsoft's Singularity), I haven't done it, and to my knowledge, no one has.
Don't thank God, thank a doctor!
That was what I said wasn't it?
;)
Compiling x86 code now brings them zero steps closer to the goal
There is MIPS, VAX, PDP10 code generators in the source code but, OpenBSD never worked on any of the weirder ones and the MIPS support is busted. I reckon they should not focus so much on the "architectures that gcc has dropped" but on the architectures gcc sucks at (everything except x86).
*smirk*
:D
That would be nice, though, right? A mobile phone compiler that can actually run at a decent speed without using up a whole flash card?
Nintendo DS Homebrew could really benefit from pcc on ARM.
LLVM is the one to watch. Currently, llvm-gcc uses GCC's front end but Apple, a major funder of LLVM, have recently released the source to clang, their C compiler. No GCC in sight. http://llvm.org/ http://heisenbug.blogspot.com/2007/07/compiler-with-good-clang.html
That's like asking if Linux runs Photoshop or World of Warcraft.
;)
It's in poor taste at the very least.
(not to mention that C++ is such an appallingly horrid language that no compiler with any sense of propriety would dream or admitting it knows about such things. One might as well ask if it's got a front end for Visual Basic. The very idea!)
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I never claimed it could be; I just said that the linux kernel is not a good or fair test of a C compiler. Are you disputing that?
I am trolling
You are right but interestingly the license grants rights over product A. Whereas the license is actually item B. I guess you hold independent copyright etc. over your license unless you use one already written. Which makes me wonder what all the licenses out there include as a paragraph to actually allow others to use (and include) their license (copyright work) with the work of the others.
Think I've just added a curiosity to my list of things to look into.
I'm not saying it's impossible. I'm saying it's pretty much impossible for one guy. And that compiler bugs are definitely not the cause of all (Or probably any) application crashes on any given platform.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Why does the compiler writer giving something a useful definition make it part of the C standard? Or even a superset? If the behavior is UNDEFINED, and you write code that depends on a particular behavior, you aren't conforming to any standard right?
I agree that implementation defined behavior makes it next to impossible to guarantee portability across different implementations. I'm guessing the spec was written that way so it wouldn't make any assumptions about the types of hardware it'd be implemented on. The best you could probably do to ensure portability is follow guidelines like these.
It is extremely difficult and next to pointless to write code that is strictly conforming. It is in fact quite useful, for instance, to use unions to re-interpret bit patterns. (Note that "portable" is something rather different than "strictly conforming," or even "conforming." Many non-conforming programs are still highly portable because of commonalities among implementations.)
For example, suppose you want to bit-reverse an entire array in memory. That is, bit 0 of the first element in the array swaps locations with bit N-1 of the last element of the array, bit 1 swaps locations with bit N-2, etc., all the way down to the middle of the array. How would you implement that as a strictly conforming ANSI C program? It turns out to be rather difficult to do correctly. (Why would you want to? Well, it's a handy way to flip bitmaps for one thing.)
First, you have to know how many bits are in each unsigned char. There could be from 8 to who-knows-how-many bits in an unsigned char. (Yes, 256-bit unsigned char are legal in ANSI C, as long as there's at least as many bits in a short int, int, long int and long long int.) So, you can't rely on any fast, cute implementations such as this ever-popular word-reversal routine:
That code is implementation defined. It cannot be part of a strictly conforming program. It can be part of a conforming program, though it only works as expected on machines whose unsigned int is 32 bits. (That happens to be over 90% of the PCs and *NIX boxes people work with these days, but that wasn't true as recently as 10 years ago.)
What about other undefined things? Well, sometimes an implementation defines them usefully. For example, consider this bit of code:
This is useful code. Chances are nearly every compiler you meet (at least, which offers 32-bit ints) will handle this correctly and tell you the endianness of the machine. That means it's reasonably portable. It also happens to be quite undefined.
Sure, it fails miserably on oddball machines with non-standard word sizes, but most programs only care to be portable amongst the vast majority of machines that have 8-bit char, 16-bit short, 32-bit int. (This is part of the reason why LP64 machines are more popular than ILP64 machines.)
In general, compilers implement a superset of the standard by providing reasonable semantics to expressions that the standard leaves undefined. For instance, on most compilers, signed arithmetic wraps around the same as unsigned arithmetic, and the values you get are exactly what you'd expect from 2s complement arithmetic, despite the fact that the standard leaves those results undefined. Heck, until the adoption of C9x, C++ style comments were not technically legal in C programs, but most compilers accepted them.
--JoeProgram Intellivision!
You are right on about this. The 80286 had the beginnings of what was required to write solid operating systems. The boundary protection and memory virtualization started giving the microprocessors the virtual memory semantics that we were used to from the mainframes. Aside from features that were missing (later added in 80386) and the loadall saveall debacle (security through obscurity failure), things were looking bright for the operating system writers targeting micros. Unfortunately, Microsoft made a decision not to use the boundary protection in their new operating system called "Windows". They ignored most of the work that Intel did providing support in the silicon for a decent micro operating system. The boundary protection could have been built into the programming language and runtime. Things would have been much better in the long term. I guess in the early days, they (MS) didn't want to use the memory space or cycles to secure the environment, although later they were willing to virtualize the entire runtime in that name (.NET).
Well, I think this is mostly a moot point. Ok, so 95% of the linux kernel is GPL, and 5% is BSD. You can feel free to copy out the lines that were originally BSD if you'd like to. Or you could just copy them from wherever the linux devs copied them from. Same effect.
You can certainly release your own code under a different license as a derivative work. Provided, of course, that the original license doesn't prohibit using the original code in derivative works that use a different license (like the GPL does).
For as much as you claim that there is mass infringement going on with license changing, it doesn't seem like many lawyers in the FOSS world seem to agree. Can you point to any authoritative sources in the FOSS world that agree with you (FSF, EFF, key spokesmen, etc?).
I am certainly not claiming there is mass infringement going on. If there was infringement, I think it was an honest mistake because someone thought it was okay to re-license someone else's code. Then Theo being Theo thought it was part of a vast Linux anti-BSD conspiracy. The fact that it was an honest mistake is why I'm willing to have these debates on Slashdot. I think it is important that we are all clear on what is legal and what is not.
Here are some links to a clarifying discussion by some people from the FSF.
I became aware of this issue (and the correct answer) during some heated debates about the GPLv3 over on Groklaw. The anti-GPL people were making the argument that the GPL was bad because it forced/allowed you to re-license BSD code without the author's consent. The pro-GPL forces made the same arguments as in the links above, saying that you are never allowed to re-license someone else's code without their permission.
We don't see the world as it is, we see it as we are.
-- Anais Nin
Unfortunately, Microsoft made a decision not to use the boundary protection in their new operating system called "Windows". They ignored most of the work that Intel did providing support in the silicon for a decent micro operating system. The boundary protection could have been built into the programming language and runtime. Things would have been much better in the long term.
16 bit Windows did use it, but just not for protection.
Originally 8086s had a simple segmentation mode without protection. Each address was built up of seg<<16|offset. Since both segment and offset were 16 bit, this limited the address space to 1MB. Famously, the designers of the IBM PC reservered the upper 384K for IO, and this is where the 640K limit came from.
Later on the 80286, protected mode was supported, where the value you loaded into a segment register was a selector, and index into a table of segments. The CPU supported different privilege levels called Rings with only the highly privileged ones allowed to create entries in this table.
16 bit Windows did used 286 protected mode - it had to to get access to memory above 1MB. When it loaded it would install a DOS extender which would switch the PC into protected mode and allow 16 bit protected mode tasks to run on top of DOS. Since the 286 didn't allow you to switch back, each call into DOS used a triple fault to reset the processor and some Bios code to jump back into Windows.
It was even possible to allocate buffers bigger than 64K. In that case, windows would set up an array of selectors for each 64K chunk. If C code wanted to access an arbitrary location in the buffer, the compiler would work out which 64K chunk it was in, load a segment register with the corrrect selector (this was a very slow operation since microcode in the 286 had to check permissions), calculate the offset and load it into one of the normal registers and then do the segment read. This was an incredibly slow process.
It's also worth pointing out that 16 bit Windows used protected mode to get access to more memory, the like Dos the OS didn't protect itself from being damaged by third party applications. And it didn't stop third party applications damaging each other. As Walter Oney put it the philosphy was that it's a personal computer after all - If you're a programmer you can do what you like to it, just like you're free to run your car without oil until it seizes up.
Once the 386 came out and allowed offsets into segments to be bigger than 64K Windows would even set the limit on the first selector to allow you to access the whole buffer with operand size overides. The 386 also supported Virtual 8086 mode, so protected mode could jump into DOS and segments would work like a 8086. But loading segment registers was still a very slow operation, and Windows NT and Linux which are both designed to stop applications corrupting each other or the system both used page tables to do it instead. But page tables don't protect against buffer overruns.
Mind you segmentation only protects against buffer overruns if you malloc the buffers. Automatic variables on the stack are not protected. And allocing a stack variable is just a subtract instruction - it is orders of magnitude faster than calling into the OS, switching to Ring 0, allocating the memory, filling in the segment table and the returning to the caller who would load the selector into a segment register. Worse, there are very few segment registers, an each time you access any buffer you need to reload one. On a 286 there is CS,DS,ES.CS and DS are needed for near code and data, so only ES is free for far pointers. The 386 has FS and GS too, but three registers with very slow loads is not a recipe for a speedy machine.
So Microsoft tried it and it was slow. If they'd have used it enough to avoid buffer overruns - i.e. malloc every buffer rather than allocating some on the stack it would have been really slow. And so all modern OSs rely on the page table for protection instead of segments so they can run on multiple processors. In x64 mode, segment limits aren't even checked by hardware anymore.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
How can a single C compiler replace a compiler collection which supports Ada, C, C++, Fortran, Java, Objective-C and Objective-C++?
Answer: It can't.
Martin
The *BSD forked something quite a bit lighter than GCC, namely GAS, in 1993; they implemented a useful feature (dynamic shared libraries, à la SunOS) with it; since the main GAS thread went to ELF and BFD, they had to support themselves their fork; it proved to be too heavy a weight for them, so they were "forced" a few years later to drop the enhancement, or at least making it deprecated/obsolete. So I do not believe forking GCC as being rational, at least for a mainstream projet like *BSD.
learn to write lisp to understand abstraction.
Learn to write correct C to understand application.
Z. Well, yeah, it implements a bunch of nice mathematical tools that are good for checking algorithms.
But do you understand the run-time?
In my opinion, C has suffered as much as it has benefited from the standardization process. (Obligatory thanks to Microsoft as one of the largest influences there.) It's a lot harder for me to understand the run-time of a C program now than it used to be, and if I can't understand the run-time, what good is it if I know my algorithm is theoretically correct? By the time it gets to the metal, timing issues and other semantics issues of getting the abstract stuff mapped to the bare metal may (for example) have pushed my checks for corner cases way out of whack.
But I look at the alternatives. Java used to be fairly understandable. Now it's fast enough to use on a lot of stuff, but it is no longer understandable. (I know that no one mentioned Java, but I just did, as an example.)
Every interpreted language I've seen makes all sorts of implicit assumptions about the run-time behavior that are counter-intuitive to me. I used to think it was just me, but when I ask fans of said language to explain, their explanations are generally full of stuff that turn out to be their personal interpretations of things they don't understand. So the best they can say is that they think they can demonstrate correctness. Or maybe they can demonstrate that they think it's correct.
Or, at any rate, that's the way it looks to me.
While I can imagine an architecture in which your loop never goes negative (explicit sign bit not involved in shifts) I can't imagine an architecture in which the loop would fail to go to zero. I mean, on any binary ALU, that 1 is just one bit, and when it runs off the top there is nothing but zeros left behind.
Hmm. Okay, I can imagine it now -- the CPU sets a flag when a shift tries to shift a one bit out of a register, and faults with the contents of the register unchanged. And you have some code somewhere that ends up catching the signal so that your loop doesn't end in a fault. Of course, multiply will be more likely to be guarded in such a way than shift.
On the one hand, yeah, people tend to write to the compiler as if it were standard.
On the other hand, BSD userland is a lot of test code written to teh GPL mark. Kernel, and other stuff will increase the balance of relatively correct..
I can tell from my last sentence that I must have been asleep by the time I hit the send button.
/* Do something that requires i to double every pass to the limit of an int. */;
What I meant to say was there is a lot of GCC compatible source code in the openBSD and netBSD distribution and packages that will test most of the points like the multiply-by-two example given. Well, maybe not that particular example, but the point I thought I was trying to make was that the bulk of the code being (relatively) standard would tend to push the development of any alternative compiler away from encouraging dependency on implementation of undefined behavior.
But thinking that over with a clear head, I can see that, _if_ some BSD programers had pet behaviors that they liked to program to, existing more-or-less correct code does not prevent such dependency being supported, and even promoted. GCC, of course, being a case in point.
However, the openBSD programers are pretty much sticklers for standard source code. More than any other group, this group is going to tend to stay away from undefined behavior, because dependence on undefined behavior is a good way to open future security holes (like the sign overflow business).
As far as DSPs, I think there is a good point to be made:
The C standard tends to try to bend over backwards to try to accomodate non-mainstream CPUs, and that is not what a standard should do. Standards should not encode all the exceptions, otherwise the exceptions become the standard.
In the case of DSPs, I can think of very few DSPs that can fully support the standard without a lot of run-time support that would get in the way of processing signals digitally. So it makes little sense to attempt to directly support DSPs in the standard.
It makes more sense for the standard to define methods by which a non-standard compiler can qualify and quantify departures from the standard.
In this case, not only do we want to be able to query the actual width of the various integer types, but we also want to be able to query the operational base, the sign behavior, and the behavior of shifts. And we want the standard to provide a way for CPU venders to declare their support for a subset or dialect of the standard.
Kind of like being able to ask someone, "Are you from Texas?" although you really can't be sure in the human case which subdialect of Texan the person you're talking to is speaking. (We is proud o' ow-uh lo-cowl dye-lectix in Texs.) Then you could know such things as that "all" has to be able to parse as a "oil" as well as "every".
In the specific case of the loop that depends on shifting bits out the top, you might enclose the loop with something like
#if ! defined STICKY_SHIFT && OPERATIONAL_BASE == 2 && ( SIGN_FORM & TWOS_COMPLEMENT )
i = 1; while ( ( i >> 1 ) > 0 )
#else
# error( "Compiler does not support this optimized algorithm." )
#end
(Man my C's getting rusty.)