Eli Zaretskii <eliz@gnu.org> writes:

> Please run the crashing command under GDB, and when it segfaults,
> produce the C-level and Lisp-level backtrace, and post them here.

Starting from scratch with the emacs-28.1 commit I can reproduce the
failure when building via

  ./configure --prefix=/home/rlb/opt/emacs-tmp --with-native-compilation

It crashes with the same segfault repeatably, i.e. if you run make
again, it crashes again on the previously mentioned "... -l comp -f
batch-byte+native-compile international/titdic-cnv.el" invocation.  That
crash output is attached below.

After adjusting the Makefile.in invocation so I could run it with gdb in
exactly the same environment once it's failing on that command, I
captured the backtrace and included it below.

With respect to the Lisp-level backtrace, I imagined you probably meant
an xbacktrace?  If so (and assuming I'm guessing right about how I
should do that), I haven't figured out how to arrange sourcing the
src/.gdbinit from the src/Makefile.in command.  I'm likely doing
something wrong, but it doesn't seem to want to load the file.

It looked like it might be because there were no debug symbols, so I
tried adding a CFLAGS=-g3 to the end of the ./configure, but that caused
the crash to disappear entirely.

Finally (and this was just a random guess based on previous experiences,
particularly with programs like guile that play (normal, traditional)
tricks with pointers/coercions/etc.) I noticed that emacs doesn't
specify -fno-strict-aliasing, and unless all the C code has been written
with that in mind, I assume that might open a window allowing the
optimizer to introduce undesirable changes.  So I added a
CFLAGS=-fno-strict-aliasing to the end of the ./configure command, and
then the build and tests worked fine (twice in a row):

  ./configure --prefix=/home/rlb/opt/emacs-tmp --with-native-compilation \
    CFLAGS=-fno-strict-aliasing

Of course that's not remotely conclusive, but if all of the C code
wasn't written with strict-aliasing in mind, then I wondered if it might
make sense to consider adding -fno-strict-aliasing as a default option.

Also, even if that ends up being desirable, I'm not sure it'll be
sufficient.  That is, I suspect I might want to run the full build/check
with -fno-strict-aliasing in a loop for a bit to make sure the clean
build/check is reliable, since I think I may have seen some test crashes
(not the build crash) on one earlier run with that option, but I'm not
sure that was a clean attempt.

The make crash: