Windows users can get GCC as a part of either Cygwin or MinGW. Unfortunately for them, GCC on Windows has always lagged behind the primary platforms like Linux on x86-32 in terms of features and robustness. This situation is particularly severe for users of the GNU Compiler for Java (GCJ). This page documents some of these shortcomings and provides suggestions for projects to improve GCC on Windows.
For general GCC on Windows information, see Windows.
GCC supports two methods for exception handling (EH):
- DWARF-2 (DW2) EH, which requires the use of DWARF-2 (or DWARF-3) debugging information. DW-2 EH can cause executables to be slightly bloated because large call stack unwinding tables have to be included in the executables.
- A method based on setjmp/longjmp (SJLJ). SJLJ-based EH is much slower than DW2 EH (penalising even normal execution when no exceptions are thrown), but can work across code that has not been compiled with GCC or that does not have call-stack unwinding information.
Platforms like Linux x86-32 have moved to DW2 EH, but Windows is still stuck with SJLJ EH. This is because it is common for Windows developers to write Windows GUI applications where they expect their event loop to catch exceptions thrown within their callback functions. Unfortunately this carries a severe penalty in environments like Java where exceptions are quite common.
DW2 EH is supported for Windows, but someone needs to implement the part that makes it possible for GUI callbacks to throw exceptions that can be caught in the main event loop, i.e. make exception-propagation work through "foreign" call frames in the stack.
Structured Exception Handling (SEH)
Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). A great overview of this mechanism can be found here.
Unfortunately, GCC does not support SEH yet. Casper Hornstrup had created an initial implementation, but it was never merged into mainline GCC. Some people have expressed concerns over a Borland patent on SEH, but Borland seems to dismiss these concerns as balderdash.
When a program tries to divide by zero or access an invalid memory location, a fault is generated for which Windows expects a handler that can recover from the error. GCJ uses such facilities on other OSs to create ArithmeticException or NullPointerException errors. GCC on Windows does not implement this handler properly (see this for some details), so GCJ is forced to generate runtime code that checks for illegal divisions -fuse-divide-subroutine and accesses -fcheck-references . This is prohibitively expensive in some cases.
GCC has problems building a shared Java runtime library (libgcj.dll) on Windows, so Windows users use a static libgcj instead. There are also some problems throwing exceptions across DLL boundaries. See this thread for some information.
GCC has problems building a shared Objective-C runtime library (libobjc.dll) on Windows, so Windows users use a static libobjc instead. This causes problems while trying to build GNUStep with GCC's runtime. The support for building a shared library is there but very bitrotten and should be removed and rewritten to use libtool support instead.