Subject: Re: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

From: Chang Xiaoduan <[email-masked]>
Date: Thu, 21 Dec 2023 11:26:05 +0800

Eli Zaretskii <[email-masked]> writes:

> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>

This is the first time I report an Emacs bug using E-mails and I am not
familiar with this kind of workflow for reporting a bug and
communication. I have raised some issues on GitHub but that is totally
different and more intuitive. Would you mind introducing me how such a
workflow came into being and why you stick with it? Any links to wiki or
articles are welcomed.

>
> The above seems to indicate the problems are somehow related to native
> compilation.  Can you build Emacs without native-compilation, and try
> reproducing this in such an Emacs?  If the problem doesn't happen in
> Emacs without native-compilation, I suspect this is a MinGW GCC bug,
> not an Emacs bug: the native code in *.eln files is somehow invalid.

I can not reproduce the crash using Emacs without native-compilation.

>
> Which version of GCC do you have installed, and is libgccjit you have
> is from the same GCC version?

I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.

>
> Or maybe we have a bug in native compilation.  Andrea, can you try
> reproducing this on GNU/Linux?
>
> Another idea is to modify comp.el to have native-comp-speed default to
> 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
> and see if the problem goes away.  If it does, that again points
> toward GCC/libgccjit and the compiler optimizations.

I have modified the `native-comp-speed` to 1, but not specified
`CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
the same crash.

After all, it looks like Eli's assumption is likely to be true. If you
are familiar with reporting a compiler bug, could you tell me how could
I verify it is indeed a MinGW GCC bug and report this to MinGW?