From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9E05A385842E; Tue, 26 Apr 2022 07:18:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E05A385842E From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03 Date: Tue, 26 Apr 2022 07:18:56 +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: alias, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 26 Apr 2022 07:18:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103662 --- Comment #23 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:22c24ba48a20a4944a50cca06449debed7d1b3f4 commit r12-8260-g22c24ba48a20a4944a50cca06449debed7d1b3f4 Author: Jakub Jelinek Date: Tue Apr 26 09:17:32 2022 +0200 testsuite: Improve unlimited_polymorphic_3.f03 [PR103662] On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote: > I have just pushed the attached fix for two UNRESOLVED checks at -O0= =C2=A0that I > hadn=C3=A2t seen. I don't like forcing of DSE in -O0 compilation, wouldn't it be better to just not check the dse dump at -O0 like in the following patch? Even better would be to check that the z._data =3D stores are both pres= ent in *.optimized dump, but that doesn't really work at -O2 or above becau= se we inline the functions and optimize it completely away (both the stores and corresponding reads). The first hunk is needed so that __OPTIMIZE__ effective target works in Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__ is considered not to match at all. 2022-04-26 Jakub Jelinek PR fortran/103662 * lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add a var definition to avoid pedwarn about empty translation unit. * gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse fr= om dg-additional-options, guard scan-tree-dump-not directives on __OPTIMIZE__ target.=