In devel:gcc/gdb testlogs, we find:
...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
UNSUPPORTED: gdb.base/auxv.exp: generate native core dump
UNSUPPORTED: gdb.base/auxv.exp: info auxv on native core dump
UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and core
...

Using a patch to print debug info about core generation, we observe:
...
[  836s] + ulimit -a -H
[  836s] core file size          (blocks, -c) unlimited
[  836s] data seg size           (kbytes, -d) unlimited
[  836s] scheduling priority             (-e) 0
[  836s] file size               (blocks, -f) unlimited
[  836s] pending signals                 (-i) 11647
[  836s] max locked memory       (kbytes, -l) 64
[  836s] max memory size         (kbytes, -m) unlimited
[  836s] open files                      (-n) 4096
[  836s] pipe size            (512 bytes, -p) 8
[  836s] POSIX message queues     (bytes, -q) 819200
[  836s] real-time priority              (-r) 0
[  836s] stack size              (kbytes, -s) unlimited
[  836s] cpu time               (seconds, -t) unlimited
[  836s] max user processes              (-u) 16384
[  836s] virtual memory          (kbytes, -v) unlimited
[  836s] file locks                      (-x) unlimited
[  836s] + ulimit -a -S
[  836s] core file size          (blocks, -c) unlimited
[  836s] data seg size           (kbytes, -d) unlimited
[  836s] scheduling priority             (-e) 0
[  836s] file size               (blocks, -f) unlimited
[  836s] pending signals                 (-i) 11647
[  836s] max locked memory       (kbytes, -l) 64
[  836s] max memory size         (kbytes, -m) unlimited
[  836s] open files                      (-n) 1024
[  836s] pipe size            (512 bytes, -p) 8
[  836s] POSIX message queues     (bytes, -q) 819200
[  836s] real-time priority              (-r) 0
[  836s] stack size              (kbytes, -s) 8192
[  836s] cpu time               (seconds, -t) unlimited
[  836s] max user processes              (-u) 4096
[  836s] virtual memory          (kbytes, -v) unlimited
[  836s] file locks                      (-x) unlimited
[  836s] + cat /proc/sys/kernel/core_pattern
[  836s] /.build/cores/%p
[  836s] + ./orphanripper make -j4 -k check//unix/-m64
check//unix/-m64/-fno-PIE/-no-pie check//unix/-m32
check//unix/-m32/-fno-PIE/-no-pie
...

I got the test-case that use core generation to work on my local machine by
hardcoding /proc/sys/kernel/core_pattern to 'core'.

It would be nice if the gdb testsuite could do the opposite: interpret
/proc/sys/kernel/core_pattern to known where to find the core.