https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77444
--
And fixes have also started coming in:
https://gcc.gnu.org/viewcvs?rev=239959&root=gcc&view=rev
Kudos for investigating and reporting the issues.
sometimes I may keep overlapping expressions in a statement to remind me of the triggers I'm looking for at this point - and would likely use some meaningful constant names for the 1 and 2
statements aren't just logic - they're often documentation too - especially on code you might not look at again for months
I used to have many arguments with a professor whose code I was working on - he would factor out everything in an expression - removing all the parentheses and rely on operator precedence - it was often impenetrable (for me) - so I'd unpack it, wrap parentheses everywhere, change single letter vars to meaningful ones etc. - he'd be in my office an hour later ranting
Yes, it needs a warning because it's kind of obvious that there is something amiss about this expression. Only the author could tell what was specifically wrong.
I would advocate for the maintenance of both expressions if the comparison is tricky
If this is a hot path that must absolutely be optimized then a comment explaining the conditions is needed
And of course, the != 2 question might change (either because of a bug or logic change) but the == 1 might still be valid, however, if you took the first one your change will break the code
If it were a blog describing a 0-day vulnerability in a given software, I wouldn't have assumed that it would have been reported.
Thankfully, the world is changing. You have languages where variables are immutable by default or can be declared so that would prevent issues as http://www.viva64.com/en/d/0108/
Maybe gcc should do better for static analysis of a program. Expressions like `a && a` or `a == 1 || a != 2` should be caught easily.