Re: GCC is 25 years old today

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 <foostuff.h> //not strictly legal AFAIK
#endif
versus:
#ifdef FOO
# include <foostuff.h>
#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).

Return to the comp.compilers page.
Search the comp.compilers archives again.