[Bug c++/50346] New: Function call foils VRP/jump-threading of redundant predicate on struct member

["scovich at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346

             Bug #: 50346
           Summary: Function call foils VRP/jump-threading of redundant
                    predicate on struct member
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: scovich@gmail.com


When compiling the following code with options `-O3 -DBUG' :

// === bug.cpp =======
struct foo {
    bool b;
    foo() : b(false) { }
    void baz();
};

bool bar();
void baz();

void test() {
    foo f;
    bool b = false;
    if (bar()) b = f.b = true;
#ifndef BUG
    if (f.b != b) __builtin_unreachable();
#endif
    if (f.b) f.baz();
}
// === end ==========

gcc fails to eliminate the second (redundant) if statement:

_Z4testv:
.LFB3:
        subq    $24, %rsp
        movb    $0, 15(%rsp)    <=== assign f.b = 0
        call    _Z3barv        <=== cannot access f.b
        testb   %al, %al
        je      .L2
        movb    $1, 15(%rsp)
.L3:
        leaq    15(%rsp), %rdi
        call    _ZN3foo3bazEv
        addq    $24, %rsp
        ret
.L2:
        cmpb    $0, 15(%rsp)    <=== always compares equal
        jne     .L3
        addq    $24, %rsp
        ret

Compiling with `-O3 -UBUG' gives the expected results:

_Z4testv:
.LFB3:
        subq    $24, %rsp
        movb    $0, 15(%rsp)
        call    _Z3barv
        testb   %al, %al
        je      .L1
        leaq    15(%rsp), %rdi
        movb    $1, 15(%rsp)
        call    _ZN3foo3bazEv
.L1:
        addq    $24, %rsp
        ret

This sort of scenario comes up a lot with RAII-related code, particularly when
some code paths clean up the object manually before the destructor runs
(obviating the need for the destructor to do it again).

While it should be possible to give hints using __builtin_unreachable(), it's
not always easy to tell where to put it, and it may need to be placed multiple
times to be effective.