GNU bug report logs - #63365
30.0.50; GCC 13.1 breaks building Emacs with native-compilation

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Cyril Arnould <cyril.arnould <at> outlook.com>
Cc: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>, "eliz <at> gnu.org" <eliz <at> gnu.org>, 65727 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>, András Svraka <svraka.andras <at> gmail.com>
Subject: bug#63365: bug#65727: 30.0.50; Build failure in MSYS2 when --with-native-compilation
Date: Wed, 15 May 2024 13:09:00 -0400

Cyril Arnould <cyril.arnould <at> outlook.com> writes:

>> Mmmh 🧐, must say it does not make much sense to me.  Are we sure these
>> results are reliably reproducible and we are not looking at some
>> statistic fluctuation of a non very reproducible issue?
>
> I understand your scepticism. However, I've ran every build 2-4 times,
> and so far my reproducibility is at 100%. As in; with the same
> configuration the build (as a whole) either always fails or is always
> successful. It does seem random however which of the byte-compile
> steps fail in the end. Maybe the -fno-optimize-sibling-calls just
> makes the failure much more unlikely.

I was more confused then sceptic 🙂

>> Anyway if marking 'mark_threads' with
>> __attribute__((optimize("no-optimize-sibling-calls"))) solves the issue
>> in a stable way I think we should compare the assembly output of the two
>> functions.
>
> I've attached the corresponding objdump -S -d (including the original
> .o files). This time I've modified thread.c so that 'mark_threads'
> comes dead last. I ran the builds another 4 times each to make
> sure. Moving the function in the source also moves it to the end of
> the dumps, makes for easier diffing:

Okay this is getting really interesting, one of the two versions seems
to be actually optimized for recursion (dunno why we could not see it
from the pass dump) so your theory seems confirmed! 😀

If you could also share the two preprocessed versions of thread.c would
be of great help.  You should be able to do it adding to your original
GCC invokation like "-E -o thread.i".

Thanks!

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.