https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #12 from Hu Lin <lin1.hu at intel dot com> --- (In reply to Hu Lin from comment #11) > (In reply to Richard Biener from comment #9) > > That that GCC doesn't promise that -ftrapv preserves all overflows and > > traps, it merely guarantees that all overflows that actually happen trap. > > So GCC is fine to contract some expressions where the overall number of > > overflows can only > > decrease. > > > > That's not a bug with -ftrapv. > > > > It is considered a bug with -fsanitize=undefined though. > > I think it doesn't mean that's not a bug with -ftrapv, it should preserve > all overflow traps. Because it doesn't work, we use -fsanitize=undefined > instead of it. > > refer: Gcc's trapv is known not always to work correctly. > > The current behavior is correct for -fsanitize=undefined, because the > integer signed overflow is well-defined, so GCC can eliminate some > variables. I just think GCC can optimize `z = c - y - c + a + y - b` to > `z = a - b`. But it doesn't mean is a bug for -fsanitize=undefined. I was wrong about signed overflow, it's undefined behavior in c++20 (https://en.cppreference.com/w/cpp/language/ub). If I'm not mistaken about the sourceļ¼ it's a bug.
