Re: MPS: Please check if scratch/igc builds with native compilation

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, May 24 2024, Gerd Möllmann wrote:
>
>> Given the choice of either ironing or trying what I described above, I
>> evaded ironing. Diff at the end. Effect none. Which lets me update my
>> beliefs so that relocs are unlikely to be the cause this time.
>
> I also think that the problem more likely somewhere else.

FWIW, some more factoids:

- A native build on macos x64 was successful.

- The native build with default speed == 2 fails with h->obj_type !=
  IGC_OBJ_FWD. It's a long story, let's just say that I could track that
  to a cons cell that is pushed onto current-load-list in an eval in
  byte-compile-eval, gets collected, and reappears again in a call to
  length. Heaven knows what's going on. The C generated by the native
  compiler looks correct to me. The arm64 assembly I don't want to read
  :-).

- A native build on arm64 with speed == 0 gets much further than the
  default build with speed == 2, but then gets a EXC_BAD_ACCESS in some
  pretty printing code when compiling char-code.el. It doesn't show the
  IGC_OBJ_FWD problem.

- In bug#70796 I found on arm64 that a native build shows the bug, a elc
  build does not.

I'm beginning to seriously take a libgccjit 14.1 bug on arm64 into
account.