[RFC][GSoC] Improving gcc on Windows targets

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.