[Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[hjl.tools at gmail dot com]

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

            Bug ID: 64921
           Summary: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
                    with -fPIC
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com

On x86-32, r220369 gave

FAIL: gfortran.dg/class_allocate_18.f90   -O0  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O2  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -g  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -Os  execution test

when -fPIC is used.  r220364 is OK.

[Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r220371 generates identical code to r220350 on this testcase.
Do you mean libgfortran.so has been miscompiled?
But then really -fPIC shouldn't matter here, as libgfortran is built with
-fpic, and I've certainly bootstrapped/regtested my patch on both i686-linux
and x86_64-linux.

[Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
I got

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xF763FACE
#1  0xF763EBDE
#2  0xF773CBBF
#3  0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
#4  0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
#5  0x8048A59 in MAIN__ at class_allocate_18.f90:?
FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test

But I couldn't reproduce it on another machine. I will keep an eye on it.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
            Summary|[5 Regression] FAIL:        |[4.9/5 Regression] FAIL:
                   |gfortran.dg/class_allocate_ |gfortran.dg/class_allocate_
                   |18.f90 with -fPIC           |18.f90

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
and 4.9 branch:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html

It is caused by r220191.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> and 4.9 branch:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
> 
> It is caused by r220191.

HJ,

I'll take a look at this tomorrow night. I find it to be enormously surprising
that r220191 is causing this regression. I rather think that I have exposed
another underlying bug.

Thanks

Paul

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #4)
> (In reply to H.J. Lu from comment #3)
> > gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> > and 4.9 branch:
> > 
> > https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
> > 
> > It is caused by r220191.
> 
> HJ,
> 
> I'll take a look at this tomorrow night. I find it to be enormously
> surprising that r220191 is causing this regression. I rather think that I
> have exposed another underlying bug.
> 
> Thanks
> 
> Paul

I've been seeing this test fail in cross-testing on arm-linux-gnueabi{hf} too.
However native testresults from gcc-testresults don't show this coming up
often. Not sure what's going on here.

Ramana

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jaydub66 at gmail dot com

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #2)
> I got
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Backtrace for this error:
> #0  0xF763FACE
> #1  0xF763EBDE
> #2  0xF773CBBF
> #3  0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
> #4  0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
> #5  0x8048A59 in MAIN__ at class_allocate_18.f90:?
> FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test
> 
> But I couldn't reproduce it on another machine. I will keep an eye on it.

Hi HJ,

Given that the error is sporadic, are you sure that the offending revisions are
not 220125 and 220130 - PR64230. The error messages that you are getting are
remarkably similar to the original report for this PR.

In the case of PR62044, the fix only applies to allocation with MOLD = derived
type. class_allocate_18.f90 involves a CLASS entity and does not use MOLD =
anything.

I will investigate if there is not some horrible kludge that is spoofing up the
allocate expression in class_allocate_18.f90 by passing the typespec through a
hidden MOLD expression. If this is not the case, there is nothing that I can
do.

I'll come back to you in about twenty minutes. I have put Janus in copy.

Cheers

Paul

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Paul Thomas from comment #6)
> (In reply to H.J. Lu from comment #2)
> > I got
> > 
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
> > 
> > Backtrace for this error:
> > #0  0xF763FACE
> > #1  0xF763EBDE
> > #2  0xF773CBBF
> > #3  0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
> > #4  0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
> > #5  0x8048A59 in MAIN__ at class_allocate_18.f90:?
> > FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test
> > 
> > But I couldn't reproduce it on another machine. I will keep an eye on it.
> 
> Hi HJ,
> 
> Given that the error is sporadic, are you sure that the offending revisions
> are not 220125 and 220130 - PR64230. The error messages that you are getting
> are remarkably similar to the original report for this PR.
> 

I don't know for sure.  This failure seems more consistent on 4.9 branch
than on trunk.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> If I have understood correctly, -fPIC is not supported on x86_64 and so,
> unless I am mistaken, I cannot help you further.

This is not how I understand comment 1.

Note that if I compile with -fsanitize=address, the executable crashes with

 allocated!
=================================================================
==73209==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000e040 at pc 0x000103b59dbd bp 0x7fff5c0a6fa0 sp 0x7fff5c0a6f98
READ of size 8 at 0x60200000e040 thread T0
    #0 0x103b59dbc 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001dbc)
    #1 0x103b595aa 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000015aa)
    #2 0x103b59889 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001889)
    #3 0x103b5a7a6 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000027a6)
    #4 0x7fff8fd1e5c8  (/usr/lib/system/libdyld.dylib+0x35c8)
    #5 0x0  (<unknown module>)

0x60200000e040 is located 0 bytes to the right of 16-byte region
[0x60200000e030,0x60200000e040)
allocated by thread T0 here:
    #0 0x103b8d1fa  (/opt/gcc/gcc4.10w/lib/libasan.2.dylib+0x2f1fa)
    #1 0x103b59642 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001642)
    #2 0x103b5a7a6 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000027a6)
    #3 0x7fff8fd1e5c8  (/usr/lib/system/libdyld.dylib+0x35c8)
    #4 0x0  (<unknown module>)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1c0400001bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400001bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400001bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400001be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400001bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 01 fa
=>0x1c0400001c00: fa fa 00 fa fa fa 00 00[fa]fa 07 fa fa fa 07 fa
  0x1c0400001c10: fa fa 06 fa fa fa 00 06 fa fa 00 00 fa fa 03 fa
  0x1c0400001c20: fa fa 00 06 fa fa 00 07 fa fa 00 fa fa fa 00 00
  0x1c0400001c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x1c0400001c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x1c0400001c50: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00

I see this for r220302, r220156, r220109, and r219830 (i.e., all the revisions
I have tested).

Note that Janus has removed the -fsanitize=undefined option at r220181, while
it worked for me provided I ran the test after install.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This is probably a duplicate of pr64849.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |4.9.3

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 64849 has been marked as a duplicate of this bug. ***

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-16
          Component|rtl-optimization            |fortran
     Ever confirmed|0                           |1

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
If I comment the line

  Deallocate (t)

the test compiled with -fsanitize=address runs without error. This is also the
case for the following variant

Program main
  Implicit None
  Type :: t1
  End Type
  Type, Extends (t1) :: t2
    Integer, Allocatable :: i
  End Type
  Type, Extends (t2) :: t3
    Integer, Allocatable :: j
  End Type
  Class (t1), Allocatable :: t
  Allocate (t3 :: t)
  if (allocated(t)) then
    print *,"allocated!"
    select type (t)
      type is (t1)
        print *, "type is t1"
      type is (t2)
        print *, "type is t2"
      type is (t3)
        print *, "type is t3"
        t%i = 42
        t%j = 99
        print *, t%i, t%j
        Deallocate (t%i, t%j)
    end select
!    deallocate (t)
  else
    call abort ()
  end if
End

which outputs at run time

 allocated!
 type is t3
          42          99

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

[mathewc at nag dot co.uk]

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

--- Comment #14 from Mat Cross <mathewc at nag dot co.uk> ---
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.

In the interim, does anyone have any bright ideas for a reasonable (few-line)
workaround?

Thanks.

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #16 from ktkachov at gcc dot gnu.org ---
I see this execution fail on aarch64-linux-gnu and arm-none-linux-gnueabihf on
the GCC 5 branch

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

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(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:

--cut here--
test ()
{
  integer(kind=8)[0:D.4089] * restrict sizes;
  integer(kind=8)[0:D.4068] * restrict sizes;
  void * _13;
  integer(kind=4) * _63;
  integer(kind=4) * _121;

  <bb 2>:
  _13 = __builtin_malloc (24);
  if (_13 == 0B)
    goto <bb 3>;
  else
    goto <bb 4>;

  <bb 3>:
  _gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1});

  <bb 4>:
  MEM[(c_char * {ref-all})_13] = MEM[(c_char * {ref-all})&__def_init_test_T4];
  sizes_22 = __builtin_malloc (8);
  MEM[(integer(kind=8)[0:D.3483] *)sizes_22][0] = 1;
  _63 = MEM[(struct t4 *)_13].k;
  if (_63 == 0B)
    goto <bb 6>;
  else
    goto <bb 5>;

  <bb 5>:
  __builtin_free (_63);

  <bb 6>:
  sizes_79 = __builtin_malloc (8);
  _121 ={v} MEM[(struct t3 *)0B].j.i;
  __builtin_trap ();

}
--cut here--

The <bb 6>: part reads from address 0x0+, and if this doesn't crash, trap insn
surely crashes program.
>From gcc-bugs-return-493320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 25 14:07:55 2015
Return-Path: <gcc-bugs-return-493320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2295 invoked by alias); 25 Jul 2015 14:07: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 1909 invoked by uid 55); 25 Jul 2015 14:07:49 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
Date: Sat, 25 Jul 2015 14:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
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: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66930-4-R7bXVPZqCA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66930-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66930-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/msg02210.txt.bz2
Content-length: 469

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf930

--- Comment #17 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Jul 25 14:07:17 2015
New Revision: 226218

URL: https://gcc.gnu.org/viewcvs?rev"6218&root=gcc&view=rev
Log:
gcc/
        PR target/66930
        * config/sh/sh.c (sh_split_movrt_negc_to_movt_xor): Add missing
        T bit register modified_between_p check.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.c

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

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de

--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
(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 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-493325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 25 16:37:08 2015
Return-Path: <gcc-bugs-return-493325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84813 invoked by alias); 25 Jul 2015 16:37:07 -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 84750 invoked by uid 48); 25 Jul 2015 16:37:01 -0000
From: "Casey at Carter dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67007] New: [c++-concepts] Deduction constraint
Date: Sat, 25 Jul 2015 16:37:00 -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: c++-concepts
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Casey at Carter dot net
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
Message-ID: <bug-67007-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/msg02215.txt.bz2
Content-length: 2742

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg007

            Bug ID: 67007
           Summary: [c++-concepts] Deduction constraint
           Product: gcc
           Version: c++-concepts
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Casey at Carter dot net
  Target Milestone: ---

r226205 ICEs compiling this program:

template <class U>
concept bool A   requires (U u) { u; };

template <class T>
concept bool B   requires (T t) { { t } -> A; };

void foo(B);

apparently while normalizing the constraints of B:

~/concept-gcc/bin/g++ -std=c++1z foo.cpp -c
foo.cpp:9:11: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1511
 void foo(B);
           ^
0x8032b1 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
        ../../gcc/cp/constraint.cc:1511
0x65794f tsubst(tree_node*, tree_node*, int, tree_node*)
        ../../gcc/cp/pt.c:12798
0x806bf0 tsubst_compound_requirement
        ../../gcc/cp/constraint.cc:1604
0x806bf0 tsubst_requirement
        ../../gcc/cp/constraint.cc:1632
0x806bf0 tsubst_requirement_body
        ../../gcc/cp/constraint.cc:1651
0x806bf0 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
        ../../gcc/cp/constraint.cc:1682
0x65103a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
        ../../gcc/cp/pt.c:16429
0x64462e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
        ../../gcc/cp/pt.c:15092
0x80591f lift_variable_initializer
        ../../gcc/cp/constraint.cc:440
0x805220 normalize_predicate_constraint
        ../../gcc/cp/constraint.cc:955
0x805220 normalize_constraint
        ../../gcc/cp/constraint.cc:993
0x805508 build_constraints(tree_node*, tree_node*)
        ../../gcc/cp/constraint.cc:1096
0x5af175 grokfndecl
        ../../gcc/cp/decl.c:7788
0x6208f6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
        ../../gcc/cp/decl.c:11202
0x621126 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
        ../../gcc/cp/decl.c:4744
0x710580 cp_parser_init_declarator
        ../../gcc/cp/parser.c:17728
0x71336d cp_parser_simple_declaration
        ../../gcc/cp/parser.c:11685
0x70c8f4 cp_parser_block_declaration
        ../../gcc/cp/parser.c:11559
0x718783 cp_parser_declaration
        ../../gcc/cp/parser.c:11456
0x716f5a cp_parser_declaration_seq_opt
        ../../gcc/cp/parser.c:11338
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

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

[rguenth at gcc dot 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.

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> 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.

transfer.4 + offset calculates the address of an element of an array.
I believe that if that code is executed, array.data is non-zero, and  of course
array.data + offset as well.

I think the the test should check for ptr2%j's nullness before deallocating
ptr2%j, instead of testing ptr2.

With a patch like this:

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..1ff7437 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived,
gfc_component *comp,
       cond->block->expr1->ts.kind = gfc_default_logical_kind;
       cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
       cond->block->expr1->value.function.actual = gfc_get_actual_arglist ();
-      cond->block->expr1->value.function.actual->expr = gfc_copy_expr (expr);
+      cond->block->expr1->value.function.actual->expr = gfc_copy_expr (e);
       cond->block->expr1->value.function.actual->next = gfc_get_actual_arglist
();
       cond->block->next = dealloc;


Unfortunately, it doesn't seem to fix the problem.

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

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On July 27, 2015 8:45:41 PM GMT+02:00, "mikael at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
>
>Mikael Morin <mikael at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>              CC|                            |mikael at gcc dot gnu.org
>
>--- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> ---
>(In reply to Richard Biener from comment #19)
>> 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.
>
>transfer.4 + offset calculates the address of an element of an array.
>I believe that if that code is executed, array.data is non-zero, and 
>of course
>array.data + offset as well.

Yes but if transfer.4 is null then transfer.4 + offset does not have to be.

Transfer.4 _is_ null in the case we segfault.  So the guard us clearly wrong.

>I think the the test should check for ptr2%j's nullness before
>deallocating
>ptr2%j, instead of testing ptr2.
>
>With a patch like this:
>
>diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
>index 218973d..1ff7437 100644
>--- a/gcc/fortran/class.c
>+++ b/gcc/fortran/class.c
>@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol
>*derived,
>gfc_component *comp,
>       cond->block->expr1->ts.kind = gfc_default_logical_kind;
> cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id
>(GFC_ISYM_ASSOCIATED);
> cond->block->expr1->value.function.actual = gfc_get_actual_arglist ();
>-      cond->block->expr1->value.function.actual->expr = gfc_copy_expr
>(expr);
>+      cond->block->expr1->value.function.actual->expr = gfc_copy_expr
>(e);
>cond->block->expr1->value.function.actual->next =
>gfc_get_actual_arglist
>();
>       cond->block->next = dealloc;
>
>
>Unfortunately, it doesn't seem to fix the problem.

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

[mikael at gcc dot gnu.org]

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

--- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #21)
> Transfer.4 _is_ null in the case we segfault.  So the guard us clearly wrong.
> 
OK, let's try something else.
Are you positive transfer.4 is null?
I don't see anything that would make it so.

If it is transfer.10 that is  null, I can see the call to __final_main_T2 that
is suspicious; it seems to pass a descriptorless array to an argument expecting
a descriptor.

Draft patch, seems to fix it

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..7a9e275 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
   final->ts.type = BT_INTEGER;
   final->ts.kind = 4;
   final->attr.artificial = 1;
+  final->attr.always_explicit = 1;
   final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL;
   if (ns->proc_name->attr.flavor == FL_MODULE)
     final->module = ns->proc_name->name;

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

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 28 Jul 2015, mikael at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
> 
> --- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #21)
> > Transfer.4 _is_ null in the case we segfault.  So the guard us clearly wrong.
> > 
> OK, let's try something else.
> Are you positive transfer.4 is null?
> I don't see anything that would make it so.

>From inspecting registers and the assembly.  The debugger cannot get
at the artificial decls.

> If it is transfer.10 that is  null, I can see the call to __final_main_T2 that
> is suspicious; it seems to pass a descriptorless array to an argument expecting
> a descriptor.
> 
> Draft patch, seems to fix it
> 
> diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
> index 218973d..7a9e275 100644
> --- a/gcc/fortran/class.c
> +++ b/gcc/fortran/class.c
> @@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
> gfc_namespace *ns,
>    final->ts.type = BT_INTEGER;
>    final->ts.kind = 4;
>    final->attr.artificial = 1;
> +  final->attr.always_explicit = 1;
>    final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL;
>    if (ns->proc_name->attr.flavor == FL_MODULE)
>      final->module = ns->proc_name->name;

even better

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

[ubizjak at gmail dot com]

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

--- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mikael Morin from comment #22)
> (In reply to rguenther@suse.de from comment #21)
> > Transfer.4 _is_ null in the case we segfault.  So the guard us clearly wrong.
> > 
> OK, let's try something else.
> Are you positive transfer.4 is null?
> I don't see anything that would make it so.

I can confirm that this patch fixes "Invalid read of size 8" valgrind memory
error for gfortran.dg/class_allocate_18.f90.
>From gcc-bugs-return-493558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 28 13:17:49 2015
Return-Path: <gcc-bugs-return-493558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 64661 invoked by alias); 28 Jul 2015 13:17:49 -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 64598 invoked by uid 48); 28 Jul 2015 13:17:44 -0000
From: "anders.granlund.0 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
Date: Tue, 28 Jul 2015 13:17: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anders.granlund.0 at gmail dot com
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:
Message-ID: <bug-67026-4-raybog8UrS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67026-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67026-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/msg02448.txt.bz2
Content-length: 1697

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg026

--- Comment #3 from Anders Granlund <anders.granlund.0 at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> Actually wait.  I think this is invalid and clang is incorrect in not
> rejecting it.  Because you have a call to a non constexpr in a constexpr
> function; does not matter if it is after a return or not.

My program is valid. Just having a call expression with a non-constexpr
function inside the body of a constexpr function is not in it self a reason for
the program to be ill-formed.

The c++ standard is quite permissive about what a function body of a constexpr
function can contain, see [dcl.constexpr]p3
(http://eel.is/c++draft/dcl.constexpr#3).

The program would however be ill-formed with no diagnostics required, if the
constexpr function could never be called without calling the non-constexpr
function. For details, see [dcl.constexpr]p5
(http://eel.is/c++draft/dcl.constexpr#5).

Also the program wold be ill-formed, if the constexpr function needs to be
called when evaluating an expression that needs to be a constant expression,
and that call would result in a call to the non-constexpr function. For
details, see [expr.const]p2 (http://eel.is/c++draft/expr.const#2) (item 2 in
the list).


I choose the return type void to avoid having to return a value in f. The test
case works with int as return type also.

  void g() {}
  constexpr int f() { return 0; g(); }
  int main() {}

Anyways GCC supports the return type void for constexpr functions. Also relaxed
requirements on constexpr functions have been implemented since version 5 of
GCC according to this:

https://gcc.gnu.org/projects/cxx1y.html

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org

--- Comment #26 from Mikael Morin <mikael at gcc dot gnu.org> ---
I'm preparing the backports.

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

[mikael at gcc dot gnu.org]

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

--- Comment #28 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Wed Aug  5 16:42:00 2015
New Revision: 226639

URL: https://gcc.gnu.org/viewcvs?rev=226639&root=gcc&view=rev
Log:
Fix random class_allocate_18.f90 failure

        PR fortran/64921
gcc/fortran/
        * class.c (generate_finalization_wrapper): Set finalization
        procedure symbol's always_explicit attribute.
gcc/testsuite/
        * gfortran.dg/class_allocate_20.f90: New.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_allocate_20.f90
Modified:
    branches/gcc-4_9-branch/gcc/fortran/ChangeLog
    branches/gcc-4_9-branch/gcc/fortran/class.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #29 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for 6.0, 5.3 and 4.9.4, closing.