Segfault on startup after building w/ GCC 12 and link-time optimization

I've noticed that the amd64 PPA build for Ubuntu 22.10 (the current development release -- not to be officially released until October) has been segfaulting for the last week or so (e.g., this build).

I was able to reproduce the issue locally after building in an Ubuntu 22.10 chroot. Here's the stacktrace:

(kinetic-amd64)root@mixtuppa:~/macaulay2# M2/usr-dist/x86_64-Linux-Ubuntu-22.10/bin/M2 --no-core --notify
-- loading startup.m2 for the first time
-- phase 1
-- executable = /root/macaulay2/M2/usr-dist/x86_64-Linux-Ubuntu-22.10/bin/M2-binary
Macaulay2, version 1.20.0.1
-- prefixDirectory = /root/macaulay2/M2/usr-dist/
-- topBuilddir     = /root/macaulay2/M2/
-- SIGSEGV
-* stack trace, pid: 2306763
 0# stack_trace(std::ostream&, bool) at ../d/main.cpp:127
 1# segv_handler at ../d/main.cpp:244
 2# 0x00007F2136671D30 in /lib/x86_64-linux-gnu/libc.so.6
 3# evaluate_evalraw at ../d/evaluate.d:1469
 4# evaluate_applyFCC at ../d/evaluate.d:563
 5# evaluate_evalraw at ../d/evaluate.d:1305
 6# evaluate_applyFCC at ../d/evaluate.d:563
 7# evaluate_evalraw at ../d/evaluate.d:1305
 8# evaluate_evalraw at ../d/evaluate.d:1269
 9# evaluate_evalraw at ../d/evaluate.d:1269
10# evaluate_evalraw at ../d/evaluate.d:1369
11# evaluate_evalraw at ../d/evaluate.d:1344
12# evaluate_evalraw at ../d/evaluate.d:1269
13# evaluate_applyFCCS at ../d/evaluate.d:845
14# evaluate_evalraw at ../d/evaluate.d:1305
15# evaluate_evalexcept at ../d/evaluate.d:1474
16# readeval3(parse_TokenFile_struct*, char, parse_DictionaryClosure_struct*, char, char, char) at ../d/interp.dd:271
17# readeval(parse_TokenFile_struct*, char, char) [clone .lto_priv.0] at ../d/interp.dd:284
18# interpFunc(ArgCell*) at ../d/main.cpp:194
19# SupervisorThread::threadEntryPoint(void*) at ../system/supervisor.hpp:100
20# GC_inner_start_routine in /lib/x86_64-linux-gnu/libgc.so.1
21# GC_call_with_stack_base in /lib/x86_64-linux-gnu/libgc.so.1
22# 0x00007F21366C62E2 in /lib/x86_64-linux-gnu/libc.so.6
23# 0x00007F2136755240 in /lib/x86_64-linux-gnu/libc.so.6
-- end stack trace *-

Usually, these command line options would give us the following:

$ M2 --no-core --notify
-- loading startup.m2 for the first time
-- phase 1
-- executable = /usr/bin/M2-binary
Macaulay2, version 1.20.0.1
-- prefixDirectory = /usr/
-- topBuilddir     = 
-- topSrcdir       = 
-- phase 2
   -- phase 3
   -- phase 4

Comparing the two, it looks like the segfault must be happening around here:

https://github.com/Macaulay2/M2/blob/ccb257c2ad7e909ecc174096079798f5fe062a41/M2/Macaulay2/m2/startup.m2.in#L353-L357

Start by reproducing the startup crash in an Ubuntu 22.10 chroot with GCC 12 and link-time optimization. Read M2/Macaulay2/m2/startup.m2.in at lines 353-357, then inspect the reported paths in d/main.cpp, d/evaluate.d, and d/interp.dd. Done means the built M2 starts with --no-core --notify and reaches phase 4 without a segmentation fault.