FWIW, I bisected with:
```
# build gcc
[...]

# build emacs
emacs_build=$(mktemp -d)
fatal cd "${emacs_build}"
CC="${prefix}"/bin/gcc CXX="${prefix}"/bin/g++ /home/sam/git/emacs/emacs-29.3/configure
CC="${prefix}"/bin/gcc CXX="${prefix}"/bin/g++ make -j$(nproc) 1>/tmp/emacs-log.txt 2>&1
ret=$?

case ${ret} in
        0)
                exit 0
                ;;
        *)
                if grep -q "Memory exhausted--use M-x save-some-buffers then exit and restart Emacs" /tmp/emacs-log.txt ; then
                        exit 1
                else
                        exit 125
                fi
                ;;
esac

exit 0
```

The bisection result is puzzling.  The linux MALLOC_ABI_ALIGNMENT define
in pa32-linux.h is replaced by the one in pa.h by the commit.  As far as
I know, the malloc alignment for hppa-linux has always been 8 bytes.  It was
never 16 bytes.  As a result, malloc'd data is insufficiently aligned for
pthreads.

I removed the define from pa32-linux.h because it didn't reflect the
actual alignment provided by malloc in glibc.

Although emacs doesn't build in Debian,
https://buildd.debian.org/status/logs.php?pkg=emacs&arch=hppa
the issue is a couple of testsuite fails.  The main difference is
Debian builds using PA 1.1 code.  The Memory exhausted error doesn't
occur there.

I confirmed that a revert of that commit on trunk lets it build, too. I'll dig more later, it's a bit too hot to have the machine on today.

Debian builds are all with gcc-13 or earlier. So, it's probably
not a PA 2.0 issue.

I did a build with gcc-14.  It fails here:
./temacs --batch  -l loadup --temacs=pbootstrap \
        --bin-dest /usr/bin/ --eln-dest /usr/lib/emacs/29.4/
Memory exhausted--use M-x save-some-buffers then exit and restart Emacs
make[4]: *** [Makefile:923: bootstrap-emacs.pdmp] Error 255

I see the following with strace running temacs:
mremap(0x623c6000, 2145378304, 2145382400, MREMAP_MAYMOVE) = 0x623c6000
mremap(0x623c6000, 2145382400, 2145386496, MREMAP_MAYMOVE) = -1 ENOMEM (Cannot a
llocate memory)
mmap2(NULL, 2145386496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
brk(0x80544000)                         = 0x745000
mmap2(NULL, 2145517568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
write(2, "M", 1)                        = 1

There are 523740 calls to mremap starting here:

mremap(0xf9a5c000, 147456, 151552, MREMAP_MAYMOVE) = 0xf99fc000
mremap(0xf99fc000, 151552, 155648, MREMAP_MAYMOVE) = 0xf9a5a000
mremap(0xf9a5a000, 155648, 159744, MREMAP_MAYMOVE) = 0xf99fa000

gdb temacs:

(gdb) p (int)MALLOC_ALIGNMENT
$2 = 8
(gdb) p (int)LISP_ALIGNMENT
$3 = 16
(gdb) p (int)MALLOC_IS_LISP_ALIGNED
$4 = 0

See src/alloc.c in emacs source.

I think LISP_ALIGNMENT is 16 because of the pthread lock alignment issue.
Since MALLOC_IS_LISP_ALIGNED is 0, we run out of memory.

Either we change the malloc alignment to 16 and put MALLOC_ABI_ALIGNMENT
back to 128, or I reinstall the lock alignment patch.  We might still run
out of memory with a malloc alignment of 16.  It not good to lie
about the malloc ABI alignment.  The lock alignment patch breaks ABI
and who know what.  It's probably best fix...

Created attachment 58576 [details]
emacs patch to adjust lisp alignment on hppa

Full build in progress.  We will have to see if ignoring 14-byte pthread lock
alignment causes issues.

I don't think this is a gcc bug.

The issue with https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ee3266b3dec4d
is that it causes emacs to reallocate malloc'd data that's not 16-byte
aligned. This doesn't happen when MALLOC_ABI_ALIGNMENT is 128 bits. There
might be a bug in mremap causing the memory exhaustion.

MALLOC_ABI_ALIGNMENT should be set to 64 when we actually need 16-byte
alignment for the pthread lock. Since we no longer need 16-byte alignment
of the pthread lock structure other than for ABI compatibility, commit
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ee3266b3dec4d should by
reverted.

Here are reverts:
Trunk:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ad2206d576603c94b0c1778c84b7f43fbf8a13b4

gcc-14:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6e1fb1f9db3b722598a7332b92f4470a7bbc9c95

Should be fixed.

Many thanks Dave!