Okay. So I noticed that even though Emacs was running, the native
compiler was segfaulting in the background. So I recompiled Emacs with
GCC and no optimizations nor patches and I still see that native compilation is
segfaulting on org-element.el. I have attached some verbose logs:
https://0x0.st/HpjT.txt

I don't know how to get a backtrace. If I run Emacs with GDB, libgccjit
gives me a segfault in the *Async-native-compile-log* but Emacs itself
does not segfault.

Sincerely,
StrawberryTea

On Thu, Aug 31, 2023, at 2:24 AM, Andrea Corallo wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: StrawberryTea <look@strawberrytea.xyz>
> >> Date: Wed, 30 Aug 2023 14:38:55 -0500
> >> 
> >> 
> >> Hi. I just set up a fresh install of Gentoo with Clang as my default
> >> compiler. At first, I was trying to compile Emacs with Clang and Emacs
> >> was finding -lgccjit but not finding the libgccjit.h header file. So I
> >> overwrote the compiler Emacs was using to GCC instead and now it
> >> compiles but segfaults when native-compiling some Elisp files.
> >> 
> >> Build log with Clang (configure error): https://bpa.st/ODFBK
> >> Build log with GCC (segfault): https://0x0.st/Hpbz.txt
> >
> > First, you apply local patches to the Emacs tree, so you are compiling
> > code that is not from our Git repository, but some variation of that.
> >
> > More importantly: it looks like you build Emacs with "-O3 -march=native",
> > which are not the default compilation switches, and cause GCC to
> > over-optimize the code.  Please try again without those switches.
> >
> > If using the default compiler switches doesn't help, please run the
> > crashing command under GDB, and when it segfaults, produce the
> > C-level backtrace and post it here.
> >
> > Please also always post the build logs as plain text or attachments to
> > your messages, instead of pointing to a URL that could some day go
> > away, and thus years from now people will be unable to see the log by
> > reading this discussion.
> >
> > Thanks.
> >
> > P.S. Adding Andrea.
> 
> Agree on everything, from this far (and for whatever reason) looks like
> the crash is in libgccjit.  So its version might be relevant as well.
> 
> Thanks
> 
>   Andrea
>