> From: Andrea Corallo > Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com > Date: Fri, 05 Mar 2021 19:22:34 +0000 > > What we have as a doc is directly in the docstring of > `comp-libgccjit-reproducer', I guess we could improve it. > > Essentially having it bound to t while compiling produces a C file > deposed where the .eln target directory. The reproducer file is attached. It is large, so I compressed it. Let me know if you see there anything that could explain the problem. > This file ELNFILENAME_libgccjit_repro.c can be just compiled linking > against libgccjit to obtain the reproducer. "To obtain the reproducer" meaning that the compiled and linked program should crash in the same way is Emacs does? I thought we crash while compiling the file and linking it to produce a shared library, not while running it. Right? > libgccjit should never segfault so if this crashes is clearly a bug. Let's see what you can find in the reproducer file. Meanwhile, I see that: . the file has DOS CRLF end-of-line format, because libgccjit opens the reproducer file in the default text mode . the file includes control characters: ^A, ^B, ^M, and others -- what are those for? I hope we cannot have ^Z there, because AFAIK text-mode writes will stop at the first such byte More generally, what is the relation between the contents of the reproducer file and the source the native compilation sees when we call gcc_jit_context_compile_to_file? Do we submit a similar file to GCC or something? IOW, can any weird characters I see in the reproducer be relevant to the actual compilation (and thus to the crash)? Thanks.