Compiler eats some code

[Romashka]

I think I've stumbled upon a serious bug in Pelles C (6.0 RC2).
The function below does not get fully compiled.
Everything between "if (!m_list_append(m_timers, timer))" and "return NULL" is completely missing from executable.
The fact that I cannot set breakpoint on those missing lines confirms this, it says "(Probably no executable code associated with this source line)".
I tried with all optimizations turned off - same result: after executing "m_list_append(m_timers, timer)" it jumps straight to "return NULL".

Code: [Select]

m_timer *m_timer_create(uint32_t period, m_timer_callback callback)
{
    m_timer *timer;


    if (!(timer = malloc(sizeof(m_timer))))
        goto exit0;

    if (!(timer->id = SetTimer(NULL, 0, period, &m_events_process_timer)))
        goto exit1;

    timer->callback = callback;

    if (!m_list_append(m_timers, timer))
        goto exit2;

    return timer;

exit2:
    KillTimer(NULL, timer->id);
exit1:
    free(timer);
exit0:
    return NULL;
}


[Romashka]

This is getting ridiculous!
Replacing "if (!m_list_append(m_timers, timer)) goto exit2;" with the following code still produces bad output:

Code: [Select]

   m_list_node *node;
    node = m_list_append(m_timers, timer);
    if (!node)
        goto exit2;

But replacing it with this code produces correct output:

Code: [Select]

   /*if (!m_list_append(m_timers, timer))
        goto exit2;*/
    m_list_node *node;
    node = m_list_append(m_timers, timer);
    if (!node)
        goto exit2;
Note that the only difference is extra comment before the code.

And to make it even more fun - this produces good result as well:

Code: [Select]

   if (!m_list_append(m_timers, timer))
        goto exit2;
    /*
        comment comment comment comment comment comment comment comment
        comment comment comment comment comment comment comment comment
        comment comment comment comment comment comment comment comment
    */

This is very similar to a bug in Visual C++ that lead to bad output in some rare situations, it was related to the fact that Visual C++ reads source code in chunks, and a bug in that procedure in some cases lead to bad output produced (unfortunately I cannot find it in internet, but I have the URL at my job, if anyone is interested).

[Romashka]

Okay, it turned out that this is actually someting in debugger GUI which jumps incorrectly, because generated assembly code is always correct.
Sorry for the noise! (still, it would be nice if debugger GUI behaved correctly)