- Rename the -fsame-fbits flag to -fpadding-on-unsigned-fixed-point
- Move the flag from a driver option to a cc1 option
- Rename the SameFBits member in TargetInfo to PaddingOnUnsignedFixedPoint
- Updated descriptions
This all looks reasonable except that I think the interpretation is exactly backwards, no? From the documentation on the option, -fpadding-on-unsigned-fixed-point causes there to be padding, i.e. the inverse of the old SameFBits; but the default value, comments, and boolean checks throughout the code are all still using the old interpretation.
Oh, having the same number of fractional bits is what leads to unsigned types having one bit of padding, and vice versa.
If this flag is set to false, then the integral and fractional parts of the unsigned types take up the whole bit width of the underlying scaled integer, with unsigned types gaining one extra fractional bit which would be taken by the sign bit in the signed types. When this flag is true, the number of fractional bits for unsigned types changes to match the signed types, but the number of integral bits stays the same, which leads to one unused padding bit.