https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94142
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Matthew Fernandez from comment #0) > This seems surprising to me. Shouldn't x and y have the same signedness as > they're both the type of the enum? It seems like somehow the type of an enum > member differs from the type of the enum itself. Because that's what C says: "The identifiers in an enumerator list are declared as constants that have type int" So as the warning tells you, y has type int. Which is because A has type int, so __typeof__(A) is int, i.e. not the same as t. As documented at https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html your enumeration type has an underlying type of unsigned int, because it has no enumeration constants with negative values. Although your example has no enumeration constants that could cause a problem, this similar example shows a case where the warning is correct: typedef enum { A, B, C = -1u } t; t x = C; __typeof__(A) y = -1; int main() { if (x == y) return 0; return 1; } This causes an implicit conversion that alters the values, which is ecactly what -Wsign-compare is designed to warn about. > Some cursory testing suggests to me this behaviour extends back to at least > the GCC 4 series. I could not find a version of Clang that has this > behaviour. Clang doesn't warn about my example above, despite having the same "wrong" result.
