-O0 bug: long bitfields triggering incorrect code #35111
Description
| Bugzilla Link | 35763 |
| Resolution | FIXED |
| Resolved on | Jan 17, 2018 07:54 |
| Version | trunk |
| OS | All |
| Blocks | #35152 |
| CC | @dbabokin,@topperc,@zmodem,@RKSimon,@sparker-arm,@Vsevolod-Livinskij |
Extended Description
clang trunk, x86_64, rev321482.
cat f.cpp
struct S {
short m0;
unsigned long long int m2 : 21;
short m3 : 16;
short m5 : 17;
short : 16;
};
S z = {-724, 388702ULL, 26720, 2792};
unsigned long long int tf_3_var_136 = 0;
void foo() {
tf_3_var_136 = ((unsigned short)(z.m0 | z.m2));
z.m5 = 0;
}
int main() {
foo();
__builtin_printf("%llu\n", tf_3_var_136);
return 0;
}
clang++ -w f.cpp -o outc; g++ -w f.cpp -o outg; ./outc; ./outg
3999203198
65406
Note that clang 5.0 also produces correct result (as gcc in the example above).
Slight massaging of the test case make the bug go. You may notice that one of the bit fields is longer than "base" type, i.e. short : 17. But this is a valid C++, according to the standard bits after the "base" type size are just "padding".
Anyway, effects triggered by this example are definitely considered as a bug by regular clang users.