Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: BGB Newsgroups: comp.compilers Subject: Re: GCC is 25 years old today Date: Fri, 30 Mar 2012 14:58:41 -0700 Organization: albasani.net Lines: 110 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-073@comp.compilers> References: <12-03-051@comp.compilers> <12-03-053@comp.compilers> <12-03-062@comp.compilers> <12-03-067@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1333180616 51322 64.57.183.58 (31 Mar 2012 07:56:56 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 31 Mar 2012 07:56:56 +0000 (UTC) Keywords: GCC, history Posted-Date: 31 Mar 2012 03:56:56 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:540 On 3/29/2012 7:17 AM, Joshua Cranmer wrote: >>>> In your views, what has been GCC's main contribution to the world of >>>> compilers? >>> >>> maybe, being free. >> >> But GCC isn't the only free compiler out there, and yet no other >> compiler, paid or free, managed to attain the same level of >> popularity. Couldn't it be possible that GCC's success is owed to >> some determining factor other than price? > > GCC is effectively required for the Linux kernel, among other things, > which creates a surprisingly effective lock-in market considering only > free software is involved :-). Once GCC was established, it means that > any serious new compiler would have to both include most of GCC's > extensions, mirror its command line (to insert itself into most build > scripts easily), and get similar performance to be taken > seriously--which amounts to a very tall order. Of course, in the past > few years, the Clang/LLVM infrastructure has progressed well enough to > be able to tackle the hegemony of GCC. yeah. my own compiler effort (even if now mostly reduced to a code parsing/processing tool, rather than being used to actually compile code) has to itself deal with a lot of both GCC and MSVC extensions. until one deals with the issue, it is likely easy to underestimate how many extensions and edge-cases may be lurking in various OS headers: GCC has __attribute__ and friends; MSVC has __declspec and friends; then, there are a number of generally shared but non-standard keywords one may also end up running into ("__cdecl", "__stdcall", "__fastcall", "__inline", ...); as well as special preprocessor directives ("#import", "#include_once", "#include_next", ...); macros using "/##*" and "*##/" to implement conditional comments; macro definitions and invocations spread over multiple lines without using '\' (AFAIK, the standard requires '\' for multi-line preprocessor stuff, but the compilers seem to relax this in certain cases, typically involving macro parameter lists, 1); little things, like omitting the names for struct members (2); GCC allows pointer arithmetic with "void *" pointers; little things, like allowing whitespace before "#" (3); ... 1: stuff like: #define FOO(x, y ) BAR(x, y) which seems to be assumed to work by the headers, but AFAIK is not valid as per the C standards (more so, whether or not this will parse as above depends on BAR also being a macro). 2: struct foo_s { struct bar_s; struct baz_s; int; char *; }; structs end up essentially directly inlined, unnamed basic fields are presumably inaccessible padding. 3: #ifdef FOO #include //not strictly legal AFAIK #endif versus: #ifdef FOO # include #endif both GCC and MSVC may try to include inline assembler in inline functions and similar as well, ... I remember encountering a good deal more than this, but I can't remember all of it at the moment. never-mind the (technically legal) wide variety of orderings which declaration keywords may appear in ("int unsigned * const volatile foo;"), and all of the places where those "__attribute__" keywords may appear in a declaration (vs, say, "__declspec", which at least so happens to fairly consistently appear before the declaration, vs, say, "int foo() __attribute__((...));"). maybe (yes, nested functions in GCC, ...): "static int foo() { int bar() { ... } bar(); }". about the only thing I really remember not encountering in headers are trigraphs and K&R style declarations, which are ironically both required to be supported by the C standard. although, in a way, all this does help point out all of these nice little features which someone somewhere was probably like "wouldn't it be so nice if the compiler allowed us to write X?..." (but, it is a little harder to know what all features exist). to some extent, my tools also emulate both GCC and MSVC command-line arguments, although generally, ignoring everything that the tool doesn't care about, also works. granted, it is much less of an issue probably in my case, since a "code processing tool" doesn't really need to faithfully emulate the compilers anywhere near as much as a drop-in compiler replacement would (it mostly just has to deal with whatever it might run into while processing headers).