bug#63365: bug#65727: 30.0.50; Build failure in MSYS2 when --with-native-compilation

[Andrea Corallo <acorallo@gnu.org>]

Cyril Arnould <cyril.arnould@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