https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127893
--- Comment #6 from [email protected] --- Additional results from the standalone reproducer make the synchronization problem clearer. Using `/usr/bin/time -lp` with 14 threads and a fixed total of 5,000,000 sequential-unformatted READ statements: ```text GCC 13 GCC 14 wall time 0.73 s 28.87 s user CPU 0.71 s 4.65 s system CPU 8.57 s 28.88 s involuntary ctx switches 72,079 10,001,226 instructions retired 7,083,936,515 142,919,438,286 cycles elapsed 24,186,322,550 72,570,777,188 block input operations 0 0 block output operations 0 0 ``` Thus the GCC 14 executable is about 39.5x slower in wall-clock time. The number of involuntary context switches increases by about 139x, from ~72 thousand to ~10 million. The GCC 14 executable also retires about 20x as many instructions to perform exactly the same number of Fortran READ statements. There are zero block input and output operations in both runs, so the slowdown is not caused by physical disk I/O. This seems consistent with the previously reported macOS `sample` profile, which is dominated by ```text data_transfer_init get_gfc_unit _pthread_rwlock_lock_slow _pthread_rwlock_lock_wait __psynch_rw_rdlock / __psynch_rw_wrlock ``` The standalone reproducer therefore appears to trigger severe rwlock contention/thrashing in the GCC 14 libgfortran unit lookup code.
