https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 23.05.2023 um 19:28 schrieb userm57 at yahoo dot com > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 > > --- Comment #10 from Stan Johnson <userm57 at yahoo dot com> --- >> The question is how much virtual memory is exposed to a user >> process, that is - how large is the address space? > > I'm not sure, but I see this: > > $ prlimit > RESOURCE DESCRIPTION SOFT HARD UNITS > AS address space limit unlimited unlimited bytes That’s indeed unhelpful. Cat /proc/maps of some executable might help > CORE max core file size 0 unlimited bytes > CPU CPU time unlimited unlimited seconds > DATA max data size unlimited unlimited bytes > FSIZE max file size unlimited unlimited bytes > LOCKS max number of file locks held unlimited unlimited locks > MEMLOCK max locked-in-memory address space 8388608 8388608 bytes > MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes > NICE max nice prio allowed to raise 0 0 > NOFILE max number of open files 1024 4096 files > NPROC max number of processes 26236 26236 processes > RSS max resident set size unlimited unlimited bytes > RTPRIO max real-time priority 0 0 > RTTIME timeout for real-time tasks unlimited unlimited microsecs > SIGPENDING max number of pending signals 26236 26236 signals > STACK max stack size 8388608 unlimited bytes > > As long as those are also the limits for portage, it should be ok. > >> Note mainline would be gcc 14.0, you can probably download a recent >> snapshot. > > ok, I've downloaded the latest gcc snapshot using git. I'll try a manual > bootstrap of that. Do you recommend that I use QEMU m68k (virt) running Debian > SID or Gentoo, or doesn't it matter? I don’t think that matters.