Link time optimization

Pete,

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.

Pete,

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.

Hi Jeff,
That is fantastic news! I've got my fingers and toes crossed that it works.
Unfortunately, when I follow good coding practice and split code up into their own modules, the speed of the code drops too. Even when compiled together, Gfortran doesn't try to optimize across the modules, and I've found no way to force it to do so, short of lto and -Whole-program options at link time.

Hi Jeff,
That's great, and thank you very much! However on my first try, the link failed .
collect2.exe: fatal error: CreateProcess: No such file or directory
compilation terminated.
Error: Last command making (target.exe) returned a bad status
Error: Make execution terminated

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

Pete,

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.