Hello everyone,
Given I have been granted the go ahead, here is a rough draft for my
proposal for GSoC 2026 to improve gcc on Windows targets. Do note that
this is a draft and as such is not perfect, in fact it is likely it has
flaws, and is subject to change. This has been submitted to gather
feedback and improvements to include in the final proposal.
I am aware that one likely serious issue for this proposed work is
finding a mentor that is free enough to watch over it as it progresses,
especially for an area considered lower priority as in the case of
Windows support. If I may, I'd like to ask for some guidance on this, as
I am also aware this is a more unconventional GSoC application for gcc.
I do know my way around the codebase, and have a rough idea on how to
implement some of the fixes already, so I can promise that I can make a
reasonable amount of progress without requiring an excessive amount of
my mentor's attention and help, which I assume is a deal breaker in many
cases.
It is my hope that this draft is at the very minimum acceptable for
review and improvement and not too terrible that it is dead on arrival.
regards,
Joseph
Summary
Improve gcc support for the Windows operating system. Accomplish this by
fixing some moderate difficulty issues within the compiler that improve
quality of life, and tackling a couple of more serious problems, such as
at least one Link Time Optimization bug and libsanitizer support. Work
on additional optional fixes if the core work can be finished earlier
than expected.
Motivation
gcc is a widely used compiler worldwide, with countless pieces of
software, some critical and high profile, relying on it to compile code,
most notably in the C and C++ languages, into native instructions for
target platforms, with many systems using it as their standard compiler.
Much infrastructure would simply not be possible without it, and gcc's
support of a wide variety of operating system and instruction set
combinations as both host and target is a key reason for its widespread
adoption. However, not every platform receives the same amount of
support, the primary platforms gcc supports receive significantly more
attention and care, and hence are significantly more battle tested, as
well as having more useful features than less well supported platforms.
The result is that gcc remains not just behind itself when it comes to
comparisons of how well it supports a primary platform compared to a
more obscure one, but also vastly inferior to other competing compilers
for that platform. One such case of gcc supporting a platform in name
but not particularly well in practice is none other than the infamous
Microsoft Windows operating system.
Windows is currently the most widely used desktop operating system, and
hence has one of the largest user bases of any gcc target operating
system. Despite this however, it faces some level of neglect, as
described above. Indeed, even the page for gcc Windows improvements
(https://gcc.gnu.org/wiki/WindowsGCCImprovements) is so outdated that it
lists native exception handling, which have already been implemented in
the compiler, as an area for improvement, and even mentions the long
defunct GNU Compiler for Java. Given Windows' widespread use and
consequent large developer community, it is unfortunate that gcc support
for this operating system is poorer than other, more primary platforms
like Linux targets. Proper gcc support on Windows would be a huge boon
to Windows developers that rely on it but currently have to work around
flaws, bugs and lack of features in the compiler, but also to Windows
developers in general, given that gcc is capable of extremely aggressive
optimization that can rival or even exceed the native Windows compiler,
Visual C, in performance of compiled code. gcc is also much less
permissive than Visual C, meaning it aids in catching bugs and improving
code quality in C and C++ source code that the Visual C compiler simply
allows. A real world example of this is JEP draft 8288293
(https://openjdk.org/jeps/8288293) aimed at porting the Java Development
Kit to the gcc compiler on Windows. Although it has yet to achieve its
goals, its use of gcc has significantly improved the robustness of the
Windows specific codebase, which had been in a state of heavy
non-conformance and disrepair before the JEP's work started. Given these
advantages gcc can bring to Windows, and the platform's large share of
developers that gcc could benefit, it would be desirable for support for
Windows to approach that of other platforms like Linux.
Description
There are several aspects of support that can be improved on Windows, so
they are listed down below. Given the scope of the proposed
improvements, this will likely be a large, 350 hour idea in terms of
implementation time.
Below are the core issues that the planned work intends to address as
the minimum set of deliverables:
- Link Time Optimization bugs on Windows. This is a huge issue for
developers attempting to use gcc for high performance code on Windows,
as tracked by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119558 where
the goal is to fix at least one of the issues reported by that meta-bug,
preferably linker bugs such as the discarding of sections wrongly deemed
to be unused by the optimizer. If the fixes prove easier than expected,
then it would be desirable to fix as many Link Time Optimization issues
reported in the bug as possible.
- Sanitizers are currently not supported on Windows. The plan is to
implement support for at least the Undefined Behaviour and Address
Sanitizer in the gcc source tree (As this is a portability issue, and
the gcc documentation for libsanitizer suggests implementing portability
fixes directly in the gcc libsanitizer fork rather than upstreaming into
LLVM) but if work finishes early, support for more, if not the complete
set of sanitizers, can be investigated.
- Support for linking options for the default Manifest on Windows. gcc
currently links the default Manifest into the binary if the distribution
provides it. More fine grained control over the linking of this manifest
through a configure option would be helpful.
- Fix the LTO jobserver option. Although I could not find the exact bug
report on bugzilla as originally reported by Richard Copley (I will link
to it in the final proposal if I manage to find it), gcc does not handle
the named semaphore case for the jobserver-auth option, which is
especially problematic given that Windows semaphores are the only
implementation for the Windows make jobserver. This causes gcc to
frequently run into trouble whenever using the LTO jobserver option.
This is not folded into the LTO issues above since this is not an issue
with the actual optimizations being performed with LTO per se, rather it
is an issue with the supporting code.
- Fix -freport-bug. This is critical as internal compiler errors on
Windows cannot be reported to gcc whatsoever without it working, at
least without a workaround that not many will know of. This stops
potentially a huge number of issues from being reported properly to the
gcc maintainers for the Windows platforms and subsequently means they
are much less likely to be fixed.
- Work on binutils PGO+LTO. It seems to not function properly on
Windows, with profile data files not being created. This is expected to
be a small fix to the Makefile only.
- Discuss potentially adding support to ld to fold an arbitrary section
into another section, perhaps via a new COFF directive or a COFF
specific extension to the existing section directive, and perhaps
support within gcc as well through the section attribute. There are many
special sections on Windows that require special handling, often through
folding into another section in the final binary. Rather than add all
required special handling, we introduce this feature instead, which not
only aids developers in the case where a given section that requires
special folding has not had proper special casing implemented in ld yet,
but also allows developers to specify that custom sections (Which are
often required for symbol sorting on Windows) are to be folded into the
desired actual section during linking rather than become their own new
section.
- Add support for gcc dependency files to use Unix style paths rather
than Windows drive prefix+colon style paths. The latter often breaks
make on Windows when using dependency files created by gcc, so this
would be helpful to have. Discuss on how to implement user control for
this feature, whether this should just become the new user default or
whether a new option should be added to choose which path style is
desired, and what that option should be named in that case.
- Add documentation on how to compile gcc for a Linux host and Windows
target with as many features enabled as possible. Although trivial
sounding, this has the potential to help gcc maintainers, who mainly
work on Linux, to compile gcc targeting Windows while running on their
host operating system. This makes it possible for them to reproduce
Windows specific bugs and test fixes, making support for Windows
significantly easier to maintain for gcc developers and heavily
improving the chances that Windows issues will be fixed.
The following goals are optional and not required, only to be worked on
once the primary goals are completed, to limit the scope of the work to
be more manageable given their inherent complexity:
- Linking against alternate C Runtimes besides MinGW-w64, but this is
low priority at the moment, and in the optional features list since this
may not help too many people and is likely more work than it is worth.
- Weak symbols do not work properly in some cases
- Implementing -Wl,--delayload for the linker as a convenience option
- Proper AVX support for Windows
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412), allowing for
optimal instruction sequences and not just unaligned instructions as the
discussion in the bug proposes, though this is unlikely to be possible
to complete given the sheer difficulty involved with this issue. This is
as such optional, and is low priority to not affect the other work
planned in this proposal.
- Structured Exception Handling support (And implement C++ exception
handling with it) for 32 bit x86
- Translate the -fvisibility= option and the visibility attribute into
the relevant Windows export and import specifiers.
- Fix a serious -gcodeview Internal Compiler Error, this is expected to
be rather difficult, so is low priority and an optional fix
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051)
- If any other bug reports for Windows regressions appear during the
coding period, and all the core deliverables have been committed to
trunk, fix the regressions if I can!
Despite the number of core issues planned to be tackled, the actual
fixes and implementation for most of them is not highly complex. The
most significant fixes planned in the core deliverables are the Link
Time Optimization fixes and libsanitizer support. In lieu of this, the
proposed timeline is as follows:
Community bonding before any actual work begins (Now to May 24):
Discuss issues with community and obtain consensus on how to approach
them, especially for deliverables that involve actual changes to the
user interface (Such as in the form of new options or extending existing
options) to discern what is best for an end user. Discuss core gcc
internals with maintainers or mentor, in preparation for the actual
implementation (I am not completely new to the gcc codebase and have a
decent understanding of it, but some proposed fixes require very deep
compiler knowledge) work. Go through gcc source and plan out the
proposed fixes for a final time before work on it properly begins.
Weeks 1-2 (May 25 to June 7)
Implement the trivial fixes (Default Manifest option, -freport-bug, LTO
jobserver fix, gcc dependency file path format, the binutils PGO+LTO
fix, documentation for compiling gcc targeting Windows on Linux) as soon
as possible, to clear the way for the more complicated issues. Submit
patches at the end of this period for review, to binutils and gcc
respectively. 2 weeks are allocated rather than one as an overestimation
in case any unforseen issues are encountered. The fixes listed for this
period are simpler, so work on them is expected to finish faster than
the other more complicated work proposed.
Weeks 3-6 (June 8 to July 5)
Begin work on the complex Windows specific issues. Attempt to complete
arbitrary section folding for ld and gcc first, as that is significantly
less complex. Work on and fix one Windows specific Link Time
Optimization bug and libsanitizer support for Undefined Behaviour and
Address Sanitizer during this period.
Weeks 7-8 (July 6 to July 19)
Submit the more complex patches for review. This, and the subsequent
editing of the patches to include suggested changes, is expected to take
some time, so a generous time slot is preemptively allocated for patch
review.
Weeks 9-12 (July 20 to August 24)
Intentionally reserved and unspecified. Used as emergency time period in
case work for the core deliverables proves to take longer than expected
and overshoots the expected timeframes. If work on all promised
deliverables completes, work on the optional fixes listed above and
submit patches for them so that Windows support benefits as much as
possible.
My next semester for my university is from April to September, but it
only consists of 2 classes for the entire semester and is not a heavy
semester, so I will be available for the full period from May 25 to
August 24 with the exception of if any unforseen emergencies, such as
hospitalization, occur during this time, but this is exceedingly
unlikely. When university midterms and endterms start (In the middle of
May and August respectively) I may be working on reduced capacity, but
otherwise will be working on Windows support full time.
This timeline estimation is of course not guaranteed to be 100% accurate
and may change during the course of the work, but will likely not change
so drastically that problems will start to arise.
Biographical Information
I am currently studying a Bachelor of Science in Computer Science at the
Singapore Institute of Management, under the University of London. I
have a special interest in open source work, and am familiar with
several important and widely used codebases, such as both the Python
reference implementation and the alternative PyPy RPython
implementation, binutils, gcc and to a lesser extent gdb. I am familiar
with the gcc specific workflow of patches via mailing list, as well as
the requirements for committing fixes to gcc. Outside of interest in
open source, I have recently started work on a compiler framework of my
own, as well as a compiler frontend using that framework. I am deeply
interested about the topic of language implementation in general, and it
would be a cherished opportunity to be able to work on gcc for GSoC
2026, especially given that the GSoC work would not just benefit myself
directly, but many others on Windows as well.
