Here’s my #mbsync #GCC workaround for #Fedora:

commit ebf6bcea7ebdba15553692777d292e59ec1d5e2e (HEAD -> master)
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Thu Aug 1 21:36:37 2024 +0300

    work around a GCC-14 optimizer issue
    
    mbsync throws SIGSEGV in sync_opened(). As it turns out for some
    reason the second entry in the local array 'boxes' is optimized
    out:
    
    (gdb) print boxes
    $1 = {0x5555556c4540, <optimized out>}
    
    Fix this by pinning the variable using a dummy inline assembly
    statement:
    
    __asm__ __volatile__("" :: "m" (boxes));
    
    This sets an invariant, which should guarantee that the compiler
    leaves 'boxes' untouched.
    
    As a comparative measure mbsync was compiled also with clang without the
    fix, and the resulting ELF binary does not have this issue.
    
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2302132
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
        if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
                mvars->chanptr->boxlist = 2;
                char **boxes[2];
+               __asm__ __volatile__("" :: "m" (boxes));
                boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
                boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
                box_ent_t **mboxapp = &mvars->chanptr->boxes;

Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=2302132

@jarkko You do know that "optimized out" means that gdb cannot access or reconstruct the value of the expression at the current point of program execution (but the point of execution of optimized code is itself a fuzzy concept), not necessarily that GCC has decided to eliminate something it should not, right?

In any event, closing a bug by adding an asm like this does not sound like a correct thing to do (as a temporary workaround it's OKish), I think you do want to understand what is going on.

I also checked GCC 13 later on:

1. LLVM 18 without the fix: works
2. GCC 13 without the fix: works
3. GCC 14 without the fix does not work.

@jamborm Looked into mbsync first time today in source level so this is best I could do in a short noticed and can read my email again so worth of investment.

@jarkko I understand. Please try Gcc 14.2 that was released this week, it has quite a few bugs fixed.

In cases like this, it is often a good idea to try compiling with -fno-strict-aliasing but if it helps it usually points to aliasing violation in the code rather than a compiler bug. With GCC 14, trying -fno-ipa-modref might be useful though AFAIK all known wrong code bugs in that pass have been fixed in 14.2.

And if it is an unknown bug, we do want a report! How difficult is it to reproduce?

@jamborm Yeah and obviously if I have bandwidth I will investigate mbsync sources further!

It is not just my main job :-)