https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> --- I don't know the full history behind this particular warning but I think a good way to find out if it can be adopted by GCC is to see the extent of the changes required to clean up the code base so it compiles with it on (I see just 2 instances of it in gcc/config/i386/i386.md in my x86_64 build). If the cleanup isn't excessive, then post a patch with it and add it to -Wextra at the same time and see what people think. Given the background it might not be a bad idea to also build a few other packages. If it turns out that the effort to clean it up is extensive due to this idiom then it might appropriate to consider tweaking the implementation of the warning and suppressing it on this case. But I would think we'd want to expose a decent amount of everyday code to the warning and see more than a couple of instances of it before making the call. My main concern is that the suppression logic not end up trading off a small number of false positives for a much larger class of false negatives. I have no data to back it up but it seems to me that disabling the warning when the operands are macros could have just such an effect. Unlike with false positives, false negatives are hard to find. (As much as I dislike one-off solutions perhaps recognizing just the EXXX == EYYY errno case could be a compromise.)
