From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B52A33865C27; Fri, 21 Jul 2023 23:26:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B52A33865C27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689982015; bh=i/AzHFLsft5bE8zeZOMNUX4FbOEW9wDGW+Z95WZEKo8=; h=From:To:Subject:Date:From; b=agw9XTSu71H5vY2qgV38hu3eEzR/PmeKTILq5PItWG5ZwwkkAeNn3Ot9Ai0yEJrNv Su6emUISGfSInMiPdEZgFZWvSsZYmzlUCNKRKaihFcxCBozgThtYgQel4J9zUZvbQa wAVfjdq0YkopYzeSSQoQeadtBRYbzm7PRsTkPL+o= From: "roland.illig at gmx dot de" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: roland.illig at gmx dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone cf_gcctarget attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110772 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=3D55598&action=3Dedit 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/35c652085d26b93b94f55312f715361ee0cd20= 43 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 l= ine 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 behavi= or. Removing the ':1' from the members in struct type_qualifier does not show t= his behavior. Compiling the code on x86_64 or i386 does not show this behavior.=