Okay. So I can reproduce it by native-compiling org.el. But instead of Emacs segfaulting, I get the following error:

Debugger entered--Lisp error: (wrong-type-argument "/home/st/.config/emacs/.local/straight/repos/org/l..." number-or-marker-p "Segmentation fault")
  signal(wrong-type-argument ("/home/st/.config/emacs/.local/straight/repos/org/lisp/org.el" number-or-marker-p "Segmentation fault"))
  comp--native-compile("/home/st/.config/emacs/.local/straight/repos/org/l..." nil nil)
  native-compile("/home/st/.config/emacs/.local/straight/repos/org/l...")
  emacs-lisp-native-compile()
  funcall-interactively(emacs-lisp-native-compile)
  command-execute(emacs-lisp-native-compile record)
  execute-extended-command(nil "emacs-lisp-native-compile" nil)
  funcall-interactively(execute-extended-command nil "emacs-lisp-native-compile" nil)
  command-execute(execute-extended-command)

Also, I have attached the logs from compiling org.el with maximum verbosity. (~80mb uncompressed)
On Fri, Sep 1, 2023, at 10:28 AM, Eli Zaretskii wrote:
> > Date: Fri, 01 Sep 2023 10:05:52 -0500
> > From: LemonBreezes <look@strawberrytea.xyz>
> > Cc: 65640@debbugs.gnu.org
> > 
> > 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.
> 
> What happens if you compile org-element.el by invoking
> emacs-lisp-native-compile?  That is:
> 
>   emacs -Q
>   C-x C-f lisp/org/org-element.el RET
>   M-x emacs-lisp-native-compile RET
> 
> Does Emacs crash if you do the above?  If so, run the above under GDB,
> and show the backtrace.
> 
> Thanks.
>