https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- The warning triggers for the clobber statement in bb 43 below. _236 is assumed to point to the beginning of the block of 512 bytes allocated by new, so subtracting a positive integer from it or adding one in excess of 512 is invalid, as is dereferencing the result: <bb 2> [local count: 118111600]: ... _229 = operator new (512); >>> _229 ... <bb 42> [local count: 50546886]: _176 = p.D.20902._M_impl.D.20257._M_finish._M_first; if (_176 != _229) goto <bb 43>; [82.57%] else goto <bb 44>; [17.43%] <bb 43> [local count: 41736564]: _236 = ASSERT_EXPR <_229, _229 != _176>; <<< _229 _177 = _236 + 18446744073709551608; p.D.20951._M_impl.D.20306._M_finish._M_cur = _177; MEM[(const struct Node * *)_236 + -8B] ={v} {CLOBBER}; <<< -Warray-bounds goto <bb 45>; [100.00%] I view the warning as helpful here (and so not a false positive even) because the test function assumes the loop inserts at least three elements into the container. If it doesn't, one of the pop() calls will crash. A more compelling test case would guard each if the pop() calls to prevent the crash, like below: #include <deque> struct Node { Node const * parent = nullptr; }; void func(Node const * n) { std::deque<Node const *> p; Node const * e = n; while (e != nullptr) { p.push_front(e); e = e->parent; } if (p.size ()) p.pop_front(); if (p.size ()) p.pop_front(); if (p.size ()) p.pop_back(); } This test case also triggers a warning, for the same reason: GCC can't determine the relationship between a deque's internal node pointers and the result of std::deque::size() (which is a function of the node pointers).