[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #18)
> (In reply to Uroš 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
> > > 
> > > 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
> > > 
> > > 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 saved,
> > > this is why removing the Deallocate (in the comment 12 example) works - the
> > > finalizer is never called then.
> > 
> > No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
> 
> [...]
> 
> I was able to trace dumps down to _.fre2 tree dump, where we have:
> 
>   <bb 12>:
>   # idx_104 = PHI <0(11), idx_122(16)>
>   offset_115 = 0;
>   ptr2_119 = (struct t3 *) offset_115;
>   _120 = &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 != 0B)
    goto <bb 19>;
  else
    goto <bb 22>;

  <bb 19>:
  _121 = ptr2_119->j.i;

we'll crash right here.

So the question is whether the frontend emits the correct test against zero:

                    offset = offset * byte_stride;
                    D.3466 = (void *) array->data;
                    D.3467 = D.3466;
                    D.3465 = 8;
                    D.3469 = 8;
                    __builtin_memcpy ((void *) &transfer.4, (void *) &D.3467,
(unsigned long) MAX_EXPR <MIN_EXPR <D.3469, D.3465>, 0>);
                    ptr2 = (struct t4 *) (transfer.4 + offset);
                    if (ptr2 != 0B)
                      {
                        {
                          integer(kind=4) stat.5;

                          if (ptr2->k == 0B)

to me it looks like if we really want to test transfer.4 (array->data) against
zero.  We do

   0x0000000000400b26 <+502>:   cmp    $0xfffffffffffffff8,%r15
   0x0000000000400b2a <+506>:   je     0x400b42 <test+530>
=> 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.
> 
> 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: <gcc-bugs-return-493428-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-65974-4-7uibWlaN6g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65974-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65974-4@http.gcc.gnu.org/bugzilla/>
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?ide974

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
Confirmed.