Fix incorrect integer promotion for bit-fields

[Copilot]

• Add integralPromotionBitfield function in cabs2cil.ml that accounts for bit-field width when computing integer promotions
• Add bitfieldWidthOfExp helper to extract bit-field width from lvalue expressions (handles nested accesses)
• Add integralPromotionE helper for expression-aware promotion
• Update doBinOp to compute effectively-promoted types (pt1/pt2) for bit-field expressions in arithmetic, shift, and pointer operations
• Update unary operators (MINUS, BNOT, PLUS) to use integralPromotionE
• Fix merge regression: restore integralPromotionE e' t in UNARY MINUS (merge from develop accidentally used integralPromotion e' t which has wrong arity)
• Update _Generic controlling expression handling to apply bit-field promotion for direct bit-field lvalue controlling expressions
• Update switch statement to use integralPromotionE
• Update variadic argument default promotion to handle bit-field arguments
• Export integralPromotionBitfield in cabs2cil.mli
• Add test case bitfield4.c for bit-field integer promotion with _Generic
• Register test in testcil.pl as testrunc11/bitfield4

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Incorrect integer promotion for bit-fields</issue_title>
<issue_description>Goblint version: nightly sha256:454ed1481fd6d78e45ed0e58e458f5a32312491f2552535b5cf18e2077447a2d.

When processed with --enable justcil, the following code snippet

struct X {
  long x : 7;
} x;

struct Y {
  long y : _Generic(x.x + 1, int : 1, default : -1);
};

produces

struct Y {
   long y : -1 ;
};

which contradicts C23 language standard. In particular, section 6.3.1.1 specifies (first paragraph on page 47):

If the original type is not a bit-precise integer type (6.2.5): if an int can represent all
values of the original type (as restricted by the width, for a bit-field), the value is converted to an
int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All
other types are unchanged by the integer promotions

In the example above, bit-field long : 8 is representable by int, and thus the value of x.x in the expression shall be promoted to int. This interpretation is consistent with behavior of clang and gcc. Goblint seems to promote based on the type alone, disregarding bit-field width.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Incorrect integer promotion for bit-fields #212

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[michael-schwarz]

@copilot Fix failing regressions.

[Copilot]

@copilot Fix failing regressions.

Fixed in a777519. The merge from develop accidentally replaced integralPromotionE e' t with integralPromotion e' t in the UNARY(MINUS) case — calling integralPromotion (type typ -> typ) with two arguments. Restored the correct two-argument call to integralPromotionE.