https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Bug ID: 110772 Summary: strange code generated for bit-field access Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: arm Created attachment 55598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55598&action=edit precompiled code that generates unrelated diagnostics In NetBSD's lint, I changed 'struct type_qualifier' from an enum to a set of bit-fields. It worked well on x86_64 but not on arm and powerpc. https://github.com/NetBSD/src/commit/35c652085d26b93b94f55312f715361ee0cd2043 On these two 32-bit platforms, lint generated some unrelated and wrong diagnostics. I tracked the difference down to a single line of code, and changing that line changes unrelated code. In the attached p5.i, applying the following diff changes not only the code in cgram.y:529, but also in cgram.y:489. $ diff -u p5.i p3.i --- p5.i 2023-07-22 00:22:30.748103516 +0200 +++ p3.i 2023-07-22 00:22:05.448298739 +0200 @@ -6424,7 +6424,7 @@ case 68: # 528 "cgram.y" { - if (!yystack.l_mark[0].y_type_qualifiers.tq_const) + if (!yystack.l_mark[0].y_seen_statement) yyerror("Bad attribute"); } # 1 "" $ gcc --version gcc (nb2 20230710) 10.5.0 $ uname -mp evbarm earmv7hfeb $ gcc -O2 -S p5.i -fverbose-asm $ gcc -O2 -S p3.i -fverbose-asm $ gcc -O2 -c p5.i $ gcc -O2 -c p3.i $ objdump -dr p5.o > p5.dis $ objdump -dr p3.o > p3.dis $ diff -u p5.dis p3.dis ... - ba8: e1b033a3 lsrs r3, r3, #7 + ba8: e3530000 cmp r3, #0 ... - 1010: e1b033a3 lsrs r3, r3, #7 + 1010: e3530000 cmp r3, #0 The code has changed in two places. Searching for the text "#7" in the p5.s file shows that the two places where the code has changed are in cgram.y:529 and cgram.y:489. I doubt that the code invokes undefined behavior, as it is fairly standard yacc code. Therefore I suspect a compiler error. Compiling the code with -Os or -O1 instead of -O2 does not show this behavior. Removing the ':1' from the members in struct type_qualifier does not show this behavior. Compiling the code on x86_64 or i386 does not show this behavior.