https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- I've done some digging now, comparing mmap calls on Solaris/i386 and Solaris/SPARC (counts and sizes each): i386: 2 4096 7 8192 5 16384 7 32768 4 65536 3 131072 2 262144 3 524288 2 1048576 1 1662976 892 2097152 2 3313664 1 4194304 total ca. 1784 MB getconf PAGE_SIZE -> 4096 sparc: 491 8192 6 16384 4 32768 3 65536 2 131072 1 262144 2 524288 1 1048576 1 2097152 986 4194304 total ca. 3947 MB getconf PAGE_SIZE -> 8192 In a next step, I disabled MAPPED_{READING, WRITING} in gcc/cp/module.cc, but that made almost no different on i386 and didn't cure the allocation failure on sparc. Looking closer at the mmap64 call chains, they are primarily from ggc_internal_alloc. So I undef'ed USING_MMAP there, with astonishing results for runtimes: * i386 with mmap in module.cc and ggc-page.cc: real 30.12 user 29.62 sys 0.14 * i386 with fileio in module.cc and mmap in ggc-page: real 29.93 user 29.50 sys 0.21 * i386 with fileio in module.cc and USING_MMAP undef'ed in ggc-page.cc: real 28.53 user 28.19 sys 0.16 * sparc with the same combination allows the test to run to complition for the first time: real 37.81 user 37.46 sys 0.14 I wonder what to make of that beyond the failing sparc testcase.