GCC中的后增量，函数调用，序列点概念

Question

There is a code fragment that GCC produce the result I didn't expect:

(I am using gcc version 4.6.1 Ubuntu/Linaro 4.6.1-9ubuntu3 for target i686-linux-gnu)

[test.c]

#include <stdio.h>

int *ptr;

int f(void)
{
    (*ptr)++;

    return 1;
}

int main()
{
    int a = 1, b = 2;

    ptr = &b;

    a = b++ + f() + f() ? b : a;

    printf ("b = %d\n", b);

    return a;
}

In my understanding, there is a sequence point at function call. The post-increment should be taken place before f().

see C99 5.1.2.3: "... called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place."

For this test case, perhaps the order of evaluation is unspecified, but the final result should be the same. So I expect b's final result is 5. However, after compiling this case with 'gcc test.c -std=c99', the output shows b = 3.

Then I use "gcc test.c -std=c99 -S" to see what happened:

        movl    $1, 28(%esp)
        movl    $2, 24(%esp)
        leal    24(%esp), %eax
        movl    %eax, ptr
        movl    24(%esp), %ebx
        call    f
        leal    (%ebx,%eax), %esi
        call    f
        addl    %esi, %eax
        testl   %eax, %eax
        setne   %al
        leal    1(%ebx), %edx
        movl    %edx, 24(%esp)
        testb   %al, %al
        je      .L3
        movl    24(%esp), %eax
        jmp     .L4
.L3:
        movl    28(%esp), %eax
.L4:
        movl    %eax, 28(%esp)

It seems that GCC uses evaluated value before f() and perform '++' operation after two f() calls.

I also use llvm-clang to compile this case, and the result shows b = 5, which is what I expect.

Is my understanding incorrect on post-increment and sequence point behavior ?? Or this is a known issue of GCC461 ??

Answer 1

In addition to Clang, there are two other tools that you can use as reference: Frama-C's value analysis and KCC . I won't go into the details of how to install them or use them for this purpose, but they can be used to check the definedness of a C program—unlike a compiler, they are designed to tell you if the target program exhibits undefined behavior.

They have their rough edges, but they both think that b should definitely be 5 with no undefined behavior at the end of your program:

Mini:~/c-semantics $ dist/kcc ~/t.c
Mini:~/c-semantics $ ./a.out 
b = 5

This is an even stronger argument than Clang thinking so (since if it was undefined behavior, Clang could still generate a program that prints b = 5 ).

Long story short, it looks like you have found a bug in that version of GCC. The next step is to check out the SVN to see if it's still present there.

Answer 2

I reported this GCC bug some time ago and it was fixed earlier this year. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814