public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "roland.illig at gmx dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/110772] New: strange code generated for bit-field access Date: Fri, 21 Jul 2023 23:26:55 +0000 [thread overview] Message-ID: <bug-110772-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-07-21 23:26 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-21 23:26 roland.illig at gmx dot de [this message] 2023-07-21 23:27 ` [Bug c/110772] " roland.illig at gmx dot de 2023-07-21 23:53 ` [Bug target/110772] " pinskia at gcc dot gnu.org 2023-07-22 0:08 ` pinskia at gcc dot gnu.org 2023-07-22 0:11 ` pinskia at gcc dot gnu.org 2023-07-22 15:21 ` roland.illig at gmx dot de 2023-07-22 15:23 ` roland.illig at gmx dot de 2023-07-22 15:29 ` roland.illig at gmx dot de 2023-07-22 15:50 ` roland.illig at gmx dot de
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-110772-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).