From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 67B0A385E440; Wed, 26 Jan 2022 07:49:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67B0A385E440 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 Date: Wed, 26 Jan 2022 07:49:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status target_milestone everconfirmed cf_reconfirmed_on Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 07:49:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104228 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Ever confirmed|0 |1 Last reconfirmed| |2022-01-26 --- Comment #1 from Richard Biener --- (gdb) p debug_rtx (insn) (insn 5 2 6 2 (parallel [ (set (reg:DI 94) (plus:DI (reg:DI 244) (const_int -112 [0xffffffffffffff90]))) (clobber (reg:CC 17 flags)) ]) "t.f90":1:9 230 {*adddi_1} (nil)) and we reference reg 244 but reg_info for this reg is NULL. The insn is the first in the BB and reg:DI 244 doesn't seem to be initialized. The instruction is expanded from ;; _10 =3D &FRAME.16.FRAME_BASE.PARENT; (insn 5 4 6 (parallel [ (set (reg:DI 94) (plus:DI (reg:DI 244) (const_int -112 [0xffffffffffffff90]))) (clobber (reg:CC 17 flags)) ]) "t.f90":1:9 -1 (nil))=20 (insn 6 5 0 (parallel [ (set (reg/f:DI 88 [ _10 ]) (plus:DI (reg:DI 94) (const_int 64 [0x40]))) (clobber (reg:CC 17 flags)) ]) "t.f90":1:9 -1 (nil)) and the underlying issue is a shared FRAME.16 local used in two functions I think: __attribute__((fn spec (". "))) voidD.27 sD.4214 () { .. struct FRAME.p FRAME.16D.4307; ... __attribute__((fn spec (". "))) voidD.27 pD.4212 () { struct FRAME.p FRAME.16D.4307; ... struct array01_character(kind=3D1) yD.4238 [value-expr: FRAME.16D.4307.yD.4308]; where the frame is unused in 's' but likely expanded there and then the expansion is used in the wrong function. Without asan the references are likely optimized away. Note in .original from the FE we see the shared variable is 'y': void s () { { static integer(kind=3D8)D.9 .yD.4216; struct array01_character(kind=3D1) yD.4238; ... void p () { static voidD.27 sD.4214 (void); struct array01_character(kind=3D1) yD.4238; ... where that 'y' is unused in 'p'.=