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

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> 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.

With the latest fix I pushed, a native build with speed == 0 also
succeeds on arm64. Hm.