bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Corallo
Subject: bug#63365: bug#65727: 30.0.50; Build failure in MSYS2 when --with-native-compilation
Date: Wed, 15 May 2024 02:38:33 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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

>> Interesting, would you mind instead of using 'printf' to try using
>> '__attribute__((optimize("O0")))' on the function to verify that the
>> issue is really an optimization?
>
> With the following, the build fails:
>
>
> diff --git a/src/thread.c b/src/thread.c
> index 040ca39511e..ffdcf420af0 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -692,6 +692,7 @@ mark_threads_callback (void *ignore)
>      }
>  }
>
> +__attribute__((optimize("O0")))
>  void
>  mark_threads (void)
>  {
>
>
> I hope this was correct? If I replace it with
> '__attribute__((optimize("no-optimize-sibling-calls")))', the build
> succeeds again.
>
> I therefore tried to compile the entirety of thread.c with -O0
> instead, upon which the build succeeded again. I'll try to add the
> '__attribute__((optimize("O0")))' in more thread.c functions to see
> which ones need it for a successful build (unless you have a better
> suggestion?).
>
> To summarize the current state:
>
> thread.c compiled with -O2: build fails
> thread.c compiled with -O2 -fno-optimize-sibling-calls: build succeeds
> thread.c compiled with -O0: build succeeds
>
> thread.c compiled with -O2 and
> - mark_threads with printf: build succeeds
> - mark_threads with
>   __attribute__((optimize("no-optimize-sibling-calls"))): build
>  succeeds
> - mark_threads with __attribute__((optimize("O0"))): build fails

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?

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.

Thanks!

  Andrea





reply via email to

[Prev in Thread] Current Thread [Next in Thread]