https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796

Matthijs van Duin <matthijsvanduin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthijsvanduin at gmail dot 
com

--- Comment #3 from Matthijs van Duin <matthijsvanduin at gmail dot com> ---
This specifically appears to happen when the constructor has parameters of
trivially copyable non-reference types, e.g. this fails:

#include <assert.h>
struct IntWrap {
        int x = 0;
        IntWrap &operator ++() { ++x; return *this; }
};
struct Pair {
        IntWrap first, second;
        Pair( IntWrap x, IntWrap y ) : first{ x }, second{ y } { }
};
int main() {
        IntWrap i;
        Pair p{ ++i, ++i };
        assert( p.first.x == 1 && p.second.x == 2 );  // FAIL (p.first.x is 2)
}

but adding a destructor to IntWrap suffices to make it pass.


Interestingly, when using simple ints there also appear to be very narrow
constraints on the initializer arguments to trigger the bug:

#include <assert.h>
struct IntPair {
        int first, second;
        IntPair( int x, int y ) : first{ x }, second{ y } { }
};
void testcase_fail() {
        int i = 0;
        IntPair p{ ++i, ++i };
        assert( p.first == 1 && p.second == 2 );  // FAIL (p.first is 2)
}
void testcase_ok_1() {
        int i = 0;
        IntPair p{ ++i, ++i };
        assert( p.first == 1 && p.second == 2 );  // ok
        int &j = i;
        IntPair q{ ++j, ++j };
        assert( q.first == 3 && q.second == 4 );  // ok
}
void testcase_ok_2() {
        int i = 0;
        IntPair p{ (int &)++i, (int &)++i };
        assert( p.first == 1 && p.second == 2 );  // ok
}
int main() {
        testcase_ok_1();
        testcase_ok_2();
        testcase_fail();
}

even though the analogous testcases for IntWrap all fail.


Related:
bug 51253  (was supposed to have fixed this but evidently missed some cases)
bug 65866  (incorrect -Wsequence-point diagnostic still being emitted)
bug 70792  (dup of bug 65866 but discussion in comments covered this case)

Reply via email to