Scoped enumerations with -Wbitfield-constant-conversion are not handled the same as fixed underlying type

[LevoDeLellis]

With the commented out enum clang/gcc give the same results which is the one I want
With the code below (using enum class) gcc gives me the expected results but clang gives me -2

#include <cstdio>

//enum E { A, B, C, D }; // <-- this gets C
enum class E { A, B, C, D }; // <-- this gets -2
struct S { E v : 2; long long i : 30; };

int main() {
	S s{E::C, -1};
	switch (s.v) {
		case E::C: printf("Got C\n"); return 0;
		default: printf("Got %d\n", s.v); return 0;
	}
}

clang version 19.1.7
Target: x86_64-pc-linux-gnu

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: None (LevoDeLellis)

With the commented out enum clang/gcc give the same results which is the one I want With the code below (using enum class) gcc gives me the expected results but clang gives me -2

#include <cstdio>

//enum E { A, B, C, D }; // <-- this gets C
enum class E { A, B, C, D }; // <-- this gets -2
struct S { E v : 2; long long i : 30; };

int main() {
	S s{E::C, -1};
	switch (s.v) {
		case E::C: printf("Got C\n"); return 0;
		default: printf("Got %d\n", s.v); return 0;
	}
}

clang version 19.1.7
Target: x86_64-pc-linux-gnu

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (LevoDeLellis)

With the commented out enum clang/gcc give the same results which is the one I want With the code below (using enum class) gcc gives me the expected results but clang gives me -2

#include <cstdio>

//enum E { A, B, C, D }; // <-- this gets C
enum class E { A, B, C, D }; // <-- this gets -2
struct S { E v : 2; long long i : 30; };

int main() {
	S s{E::C, -1};
	switch (s.v) {
		case E::C: printf("Got C\n"); return 0;
		default: printf("Got %d\n", s.v); return 0;
	}
}

clang version 19.1.7
Target: x86_64-pc-linux-gnu

[AaronBallman]

A scoped enumeration has a fixed underlying type of type int, you can see this more clearly with this code example: https://godbolt.org/z/8hhYcTWE5

I think GCC's behavior is a bit odd: https://godbolt.org/z/Wf6rdfzPP

The issue seems to have to do with implicit conversion of the bit-field in the switch condition. In Clang, that is always being treated as a signed type. In GCC, it seems to be treated as a signed type only when the fixed underlying type is explicitly specified as a signed integer. I believe this is:

https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html

Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int.

When I give the enumeration a negative value, then GCC's behavior matches Clang's: https://godbolt.org/z/GK5eWo1zh

[LevoDeLellis]

A scoped enumeration has a fixed underlying type of type int, you can see this more clearly with this code example: https://godbolt.org/z/8hhYcTWE5

I think GCC's behavior is a bit odd: https://godbolt.org/z/Wf6rdfzPP

The issue seems to have to do with implicit conversion of the bit-field in the switch condition. In Clang, that is always being treated as a signed type. In GCC, it seems to be treated as a signed type only when the fixed underlying type is explicitly specified as a signed integer. I believe this is:

https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html

Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int.

When I give the enumeration a negative value, then GCC's behavior matches Clang's: https://godbolt.org/z/GK5eWo1zh

I'm not going to say if you're right or wrong. But if the behavior isn't changed then there should at minimum be a warning if not an error. Some warning I can see using -Wall.

[AaronBallman]

I'm not certain this would end up in -Wall because the behavior is implementation-defined and so it's reasonable for different implementations to take a different stance. However, we have -Wgcc-compat and this seems like a reasonable thing to diagnose under that flag.

[LevoDeLellis]

I could see people not wanting to use gcc-compat and want to error on the code above.

I caught this problem while writing a test so it didn't take me more than a minute to realize what's going on. If someone changed their enum to enum class and hit this problem it would take a lot of time to debug, especially if they don't care about gcc compatibility, which might be most who don't program for linux or embeded. There's two ways to easily cause this bug, adding class to the enum, or adding (or changing) a bitfield. It'd be very hard to notice

[AaronBallman]

I could see people not wanting to use gcc-compat and want to error on the code above.

Sure, we would probably have a dedicated flag for just this scenario and the flag would be under -Wgcc-compat, so you can either enable it explicitly or get it with the other GCC compatibility issues.

Additionally, I think this code should be diagnosed:

enum class E : int { A, B, C, D };
struct S { E v : 2;  } s{E::C};

for exactly the same reason that we already diagnose this code:

enum E : int { A, B, C, D };
struct S { E v : 2;  } s{E::C};