gnm: descriptor enum bitfields narrower than enum range (15 GCC warnings) - preferred fix direction?

[CEnnisgit]

Building with g++-14 produces 15 warnings of this form:

rpcsx/gpu/lib/gnm/include/gnm/descriptors.hpp:25:14: warning: 'gnm::VBuffer::dfmt' is too small to hold all values of 'enum gnm::DataFormat'
rpcsx/gpu/lib/gnm/include/gnm/descriptors.hpp:24:17: warning: 'gnm::VBuffer::nfmt' is too small to hold all values of 'enum gnm::NumericFormat'
rpcsx/gpu/Registers.hpp:150:23: warning: 'amdgpu::CbColorInfo::<unnamed union>::<unnamed struct>::dfmt' is too small to hold all values of 'enum gnm::DataFormat'

The bitfield widths are hardware-mandated (V# has a 4-bit dfmt/3-bit nfmt), and the warning fires because the shared DataFormat enum spans T#'s wider range (up to kDataFormat1Reversed = 0x3C, needing 6 bits). So the code is presumably correct for the values hardware can actually deliver — but the warning can also mask a real future truncation bug, and it's ~25% of the total first-party warning count in a default build.

Before proposing a patch, which direction do you prefer?

1. Typed accessors: declare the fields as std::uint32_t dfmt : 4; etc. and add DataFormat dataFormat() const accessors — type-safe at the boundary, but touches every use site.
2. Targeted suppression: #pragma GCC diagnostic ignored "-Wbitfield-enum-conversion"-style guards around the descriptor structs, keeping the current API.
3. Leave as-is if you consider the warning acceptable noise.

Happy to implement whichever fits the project's direction (context: verified g++-14/clang-20 build matrix in #119/#120).

🤖 Generated with Claude Code

https://claude.ai/code/session_01WyB6A1ZejZwDLADJ9J525Y