bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Maybe you could try my same libgccjit version, this would confirm if
>> it's a libgccjit version specific bug or it's OS specific.
>>
>> In case you can build any libgccjit easily from the gcc repo following
>> [1].
>
> Homebrew libgccjit unforunately only supports a pre-built version 14, or
> --HEAD which so far never built successfully.
>
> My own attempts to build from GCC git also failed so far because of
> conflicting dependencies, and I didn't want to mess that much with my
> system. Also, I found GCC's use, or non-use, of branches and tags pretty
> confusing, and couldn't find an up-to-date description how that's
> intended to work. Anyway, I've given up on that.

I think just everything in releases/gcc-* is supposed to be release
ready, but there are also tags (ex refs/tags/releases/gcc-14.1.0).

Anyway I compiled libgccjit based on current releases/gcc-14 and run on
my AArch64 testbench without being able to observe the issue.

>> Another approach would be to add the ";; no-native-compile: t" cookie by
>> bisection to our .el files to discover if a specific compilation unit
>> being native compiled is causing the issue you observe.
>
> I thought about something like that to at least find the place where
> things go astray, but - besides the fact that that would take me forever
> - in the end I would be in the same position that I was with igc: a
> thousandt lines arm64 assembly, C code that looks okay, and so on...

I don't think so, by bissection is typically few steps and once the CU
is indentified we tipically narrow down the function.  With this
technique in the past we worked on non trivial bugs with success.

> So, won't happen, sorry :-)

No worries I'm not the one affected ;)

  Andrea