From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77421 invoked by alias); 27 Jul 2015 07:57:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 76901 invoked by uid 48); 27 Jul 2015 07:57:23 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90 Date: Mon, 27 Jul 2015 07:57:00 -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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.4 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-SW-Source: 2015-07/txt/msg02317.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D64921 --- Comment #19 from Richard Biener --- (In reply to Uro=C5=A1 Bizjak from comment #18) > (In reply to Uro=C5=A1 Bizjak from comment #17) > > (In reply to Mat Cross from comment #14) > > > For the record, perhaps it is of interest for me to note that we are = running > > > into this (cf. PR64230 comment 9) on code like > > >=20 > > > Program test > > > Implicit None > > > Type :: t1 > > > Integer, Allocatable :: i > > > End Type > > > Type :: t2 > > > Integer, Allocatable :: i > > > End Type > > > Type, Extends (t1) :: t3 > > > Type (t2) :: j > > > End Type > > > Type, Extends (t3) :: t4 > > > Integer, Allocatable :: k > > > End Type > > > Call s > > > Print *, 'ok' > > > Contains > > > Subroutine s > > > Class (t1), Allocatable :: x > > > Allocate (t4 :: x) > > > End Subroutine > > > End Program > > >=20 > > > Since the crash is in bad compiler-generated finalization code (since= 4.9), > > > and given that (if I recall correctly) gfortran is using the Fortran = 2008 > > > semantics for entities declared in a main program being implicitly sa= ved, > > > this is why removing the Deallocate (in the comment 12 example) works= - the > > > finalizer is never called then. > >=20 > > No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce: >=20 > [...] >=20 > I was able to trace dumps down to _.fre2 tree dump, where we have: >=20 > : > # idx_104 =3D PHI <0(11), idx_122(16)> > offset_115 =3D 0; > ptr2_119 =3D (struct t3 *) offset_115; > _120 =3D &ptr2_119->j; This isn't a dereference, it's just an address computation. Iff j is not at offset zero then of course... if (_120 !=3D 0B) goto ; else goto ; : _121 =3D ptr2_119->j.i; we'll crash right here. So the question is whether the frontend emits the correct test against zero: offset =3D offset * byte_stride; D.3466 =3D (void *) array->data; D.3467 =3D D.3466; D.3465 =3D 8; D.3469 =3D 8; __builtin_memcpy ((void *) &transfer.4, (void *) &D.346= 7, (unsigned long) MAX_EXPR , 0>); ptr2 =3D (struct t4 *) (transfer.4 + offset); if (ptr2 !=3D 0B) { { integer(kind=3D4) stat.5; if (ptr2->k =3D=3D 0B) to me it looks like if we really want to test transfer.4 (array->data) agai= nst zero. We do 0x0000000000400b26 <+502>: cmp $0xfffffffffffffff8,%r15 0x0000000000400b2a <+506>: je 0x400b42 =3D> 0x0000000000400b2c <+508>: mov 0x8(%r15),%rdi and %r15 is zero, so offset is _not_ zero here (but ends up constant propagated and we "optimize" the compare - offset seems to be 8). > This can't be right, we have a dereference from zero. If the frontend > produced correct code, then tree-optimization passes made a mess here. >=20 > CC Richi. >>From gcc-bugs-return-493428-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 27 08:03:54 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 128002 invoked by alias); 27 Jul 2015 08:03:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 127956 invoked by uid 48); 27 Jul 2015 08:03:50 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/65974] [5/6 Regression] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods Date: Mon, 27 Jul 2015 08:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.1.1 X-Bugzilla-Keywords: diagnostic 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: 5.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_known_to_work keywords cf_reconfirmed_on cc everconfirmed short_desc target_milestone cf_known_to_fail Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg02318.txt.bz2 Content-length: 1148 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Known to work| |4.9.3 Keywords| |diagnostic Last reconfirmed| |2015-07-27 CC| |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Bogus |[5/6 Regression] Bogus |deprecated-declarations |deprecated-declarations |warnings for inline |warnings for inline |definitions of deprecated |definitions of deprecated |virtual methods |virtual methods Target Milestone|--- |5.3 Known to fail| |5.1.0, 5.2.0, 6.0 --- Comment #2 from Richard Biener --- Confirmed.