Build 3882 should fix the issue as well as some pretty severe, related compiler issues introduced in 3.28.

The issue, it turns out, is that the compiler is building a UNIX-like path to lto-wrapper.exe, which is used for LTO when linking the executable.  In many cases, this path being UNIX-y (forward-slashed path separators) isn't much of a problem.  However, once spaces are introduced into the compiler path, it uses UNIX escaping, preceding each with a backslash.  On Windows, the operating system ends up seeing a nonsense path.  Since the default Simply Fortran installation location is C:\Program Files (x86)\, it ends up breaking LTO.  It wouldn't break if the installation path didn't include spaces, but that solution is nonsensical on Windows, especially in 2023.

I've made changes so that the full path to lto-wrapper.exe is generated in a Windows-specific manner, and the compiler appears to be working now.  We should have a new build up today.

That's curious, it looks like something wasn't picked up during packaging or there's a hard-coded path issue.  I'll look into it tomorrow morning, first thing.

Is there a path setting or something else I should set?
Cheers,
Pete

Version 3.28 is now available with Link Time Optimization on Windows.  You can enable the feature from Project Options under Code Generation:

It appears that the LTO plugin for our compiler wasn't being built properly because of how we link the compiler itself (the compiler is statically linked wherever possible).  However, a rebuild that just finished looks promising.  I'll start testing things today.

I haven't looked into it in detail yet.  Before the next release, we can see if a new GNU binutils will work better than previous attempts.

I'll have to look at my notes, but there was a reason why we didn't support LTO if I'm not mistaken.  That was a long time ago, however.  I'll see what I can do.