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@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@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of hto@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev