Is there any better, truer reason to bash something other than the fact it
has flaws? I don't bash it because it's made by black or Chinese people, I
don't bash it because it's FOSS, I don't bash it because of its name... I
bash it because it's broken.
Of course there's many projects that use it. There's also many countries
that were communist only 20 years ago. As you've implied, most projects use
gcc because they don't have a choice, not because it's a better compiler.
NetBSD couldn't use anything else for being able to target the dozen of
architectures it already does. ReactOS itself can't use anything else if it
wants to fully support Linux. But just because projects are forced to use a
compiler doesn't make that compiler good. The reason they all use gcc is
*lack of choice*, the very fundamental reason that FOSS exists. Just like
Windows is full of flaws, yet used in 90% of computers worldwide, so is GCC,
and the reason is lack of choice and of freedom.
Besides, just like Windows has a very strong internal architecture and at
its core is a remarkable OS, so is GCC as a compiler. Some of its developers
are true compiler designers and some work for large companies, many of which
even hold and license patents to GCC. The optimizer in GCC is very powerful
and can even rival MSVC in some cases. The cases where it doesn't cause a
bug. Because this *is* the problem behind GCC! It's a remarkable, powerful
and portable compiler, yet it is unreliable and sometimes downright stupid.
Recall your unsuccessful warnings patch to emulate MSVC. Recall the 64-bit
pointer bug I discovered. Recall the the lack of useful pragmas that other
compilers support. Recall the inability to use STDCALL as default which
means Fireball had to spend a week to "convert" a DDK sample to ReactOS and
which makes *any* DDK code uncompilable by GCC (purposeful sabotage?).
Recall the register allocation bug 2 years ago which used ebx *before* push
ebx to save it, and I can name more.
Sure, a compiler can have bugs, but on this level, it is simply
unacceptable. I've found two MSVC bugs in my lifetime, reported them, and
both got fixed within weeks... without creating two more bugs! The GCC team
still can't put software engineering in places. It's not an agile project,
it's an aging project. Just look through their code and you'll quickly
realize why so many bugs appear and why the compiler is unreliable. Instead
of choosing a target release, and making it feature complete, then spending
months to fix every single bug reported, they make a new release every other
month, with new features and fix the bugs in the previous release. But of
course, adding so many new features causes more new bugs to appear! Just
look through their bugzilla to see the hilariously pathetic bugs GCC
releases have had. I recall one bug which incorrectly interpreted print(--i)
and print (i--).
So while it's great that they target so many architectures, gcc remains an
aging beast which is likely to exhibit more and more bugs, and which will
continue to stifle FOSS compiler innovation by being the only choice. GCC is
truly the Windows of the FOSS compiler world. If you really care about open
source and about giving Windows developers a reason not to use MSVC,
OpenWatcom, Borland, Intel, etc, then re-write the win32 port of GCC from
scratch, make it lean, make it mean, and get a team behind it that knows the
basics of software architecting and engineering.
Best regards,
Alex Ionescu
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
Behalf Of Thomas Weidenmueller
Sent: April-25-07 8:52 AM
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change,
waste more stack space.
While you love to bash gcc just because it has it's flaws there's many
reasons so many projects use it, even commercial ones.
MSVC/Intel/Whatever isn't really free. The number of systems they target
is comperatively low and most importantly you rely on the vendor as no
sources are available. They may be better in certain areas but not in
all, and in some they're worse. All of them have bugs, not just gcc...
And the most important thing: There's no other compiler that allows you
to target that many different architectures as gcc.
Besides, adding a standard calling convention feature to gcc shouldn't
be that big of a deal... These things are done with symbol attributes,
maybe I'm going to work on something like that in the summer.
- Thomas
Alex Ionescu wrote:
That's all great except that every other compiler
on the planet lets you
specify the default convention PER PROJECT. Are you saying that with GCC,
I
need to recompile the compiler for every single
application I want to
ship?
Maybe I have a fastcall stub DLL, a stdcall program
and a cdecl C
compatible
DLL. I need three compilers for that? That's
rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been
broken since 2.95.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
Behalf Of hto(a)mail.cnt.ru
Sent: April-24-07 9:09 PM
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change,
waste more stack space.
stdcall default can be by altering spec file. If
mingw/cygwin don't
update there spec file in gcc that is there problem. As well there is a
flag to make stdcall default |-mrtd. Little bit of a confusing name.
Yes its provided for some strange reason mingw and cygwin don't use it.
Windows is not the only OS with stdcall default. Some unix's its also
default nothing that strange other than mingw/cygwin not using it. If
in time rosbe becomes its own complier in gcc with its own spec file
there is not reason why reactos cannot have it. Its the maintainers of
mingw/cygwin that have set the defaults without it. So over the stdcall
one either get up mingw/cygwin ribs or request rosbe gets a spec file of
its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on
different machines.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev