[Bug fortran/64986] New: class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[Bug fortran/64986] New: class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[ubizjak at gmail dot com]

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

            Bug ID: 64986
           Summary: class_to_type_4.f90: valgrind error: Invalid
                    read/write of size 8
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com

/ssd/uros/gcc-build/gcc/gfortran -B /ssd/uros/gcc-build/gcc -B
/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/ -L
/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/.libs/ -L
/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs/ -O2 -g
class_to_type_4.f90

$ valgrind ./a.out
==991== Memcheck, a memory error detector
==991== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==991== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==991== Command: ./a.out
==991== 
==991== Invalid read of size 8
==991==    at 0x401F8F: MAIN__ (class_to_type_4.f90:58)
==991==    by 0x40076C: main (class_to_type_4.f90:63)
==991==  Address 0x51afcb8 is 8 bytes inside a block of size 104 free'd
==991==    at 0x4A07CE9: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==991==    by 0x401F8E: MAIN__ (class_to_type_4.f90:58)
==991==    by 0x40076C: main (class_to_type_4.f90:63)
==991== 
==991== Invalid write of size 8
==991==    at 0x401FAB: MAIN__ (class_to_type_4.f90:58)
==991==    by 0x40076C: main (class_to_type_4.f90:63)
==991==  Address 0x51afcb8 is 8 bytes inside a block of size 104 free'd
==991==    at 0x4A07CE9: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==991==    by 0x401F8E: MAIN__ (class_to_type_4.f90:58)
==991==    by 0x40076C: main (class_to_type_4.f90:63)
==991==

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[ubizjak at gmail dot com]

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

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

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
The testcase is from PR63205, CC author.
>From gcc-bugs-return-476515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 18:33:06 2015
Return-Path: <gcc-bugs-return-476515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9450 invoked by alias); 9 Feb 2015 18:33:06 -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 8459 invoked by uid 48); 9 Feb 2015 18:33:02 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63205] [OOP] Wrongly rejects  type = class (for identical declared type)
Date: Mon, 09 Feb 2015 18:33: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: 4.9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pault at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63205-4-3yvJxH9f5J@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63205-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63205-4@http.gcc.gnu.org/bugzilla/>
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-02/txt/msg00848.txt.bz2
Content-length: 326

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

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
Reopening, something is wrong with the testcase:(In reply to Paul Thomas from
comment #11)
> Fixed on trunk, aka 5.0.0

The added testcase fails with valgrind due to memory errors, please see
PR64986.
>From gcc-bugs-return-476516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 18:34:44 2015
Return-Path: <gcc-bugs-return-476516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24716 invoked by alias); 9 Feb 2015 18:34:44 -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 24585 invoked by uid 48); 9 Feb 2015 18:34:36 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63205] [OOP] Wrongly rejects  type = class (for identical declared type)
Date: Mon, 09 Feb 2015 18:34: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: 4.9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pault at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63205-4-uQPmSpCsAP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63205-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63205-4@http.gcc.gnu.org/bugzilla/>
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-02/txt/msg00849.txt.bz2
Content-length: 476

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

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

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

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paul Thomas from comment #11)

Reopening.
>From gcc-bugs-return-476517-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 18:43:37 2015
Return-Path: <gcc-bugs-return-476517-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4194 invoked by alias); 9 Feb 2015 18:43:37 -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 4168 invoked by uid 48); 9 Feb 2015 18:43:33 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/63513] Error to build gcc loaded from svn
Date: Mon, 09 Feb 2015 18:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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: cf_gcctarget bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-63513-4-daD9eKMHW0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63513-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63513-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-02/txt/msg00850.txt.bz2
Content-length: 655

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-apple-darwin13.4.0
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-02-09
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does this happen still?  I know other folks have built a compiler for
x86_64-apple-darwin13.4.0 natively.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-13
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compelling the test with -fsanitize=address leads to an error at run time.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[paul.richard.thomas at gmail dot com]

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

--- Comment #3 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Dear Uros and Dominique,

I'll try to get to this when I can.  I have a horrible feeling that it
is the old problem of array constructors within array constructors all
of which are allocatable components. I have stared and stared at this
one and have not found the fault.

All the best

Paul

PS I have marked the message as being 'unread' as a reminder :-)

On 13 February 2015 at 11:37, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
>
> Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |NEW
>    Last reconfirmed|                            |2015-02-13
>      Ever confirmed|0                           |1
>
> --- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Compelling the test with -fsanitize=address leads to an error at run time.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Reduced test

program test
  implicit none
  type t
    integer :: ii
  end type t
  type, extends(t) :: u
    real :: rr
  end type u
  type, extends(t) :: v
    real, allocatable :: rr(:)
  end type v
  type, extends(v) :: w
    real, allocatable :: rrr(:)
  end type w

  type(v) :: b(3)

  b = func7() ! scalar daughter type to array - alloc comps in parent type

contains

  function func7() result(res)
    class(v), allocatable :: res
    allocate (res, source = w(3,[10.0,20.0],[100,200]))
  end function func7

end program test

There is no problem with the original test once the following lines are
commented

  b = func7() ! scalar daughter type to array - alloc comps in parent type
  if (any (b(2)%rr .ne. [10.0,20.0])) call abort

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

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

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
JFTR: starting with a revision in the range (221618:221635] this fails somewhat
similarly for cris-elf; the simulator reports an invalid memory access (any
optimization level, different addresses) like so:

PASS: gfortran.dg/class_to_type_4.f90   -O0  (test for excess errors)
core: 4 byte read to unmapped address 0x63af0 at 0x2080c
program stopped with signal 11 (Segmentation fault).
FAIL: gfortran.dg/class_to_type_4.f90   -O0  execution test

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> JFTR: starting with a revision in the range (221618:221635] this fails
> somewhat similarly for cris-elf; the simulator reports an invalid memory
> access (any optimization level, different addresses) like so:

The test has been introduced at revision r220482, compiling it with an earlier
revision gives an ICE and I get the valgrind errors with r220509.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Further reduced test:

program test
  implicit none
  type t
    integer :: ii
  end type t
  type, extends(t) :: v
    real, allocatable :: rr(:)
  end type v

  type(v) :: b(3)

  b = func7() ! scalar daughter type to array - alloc comps in parent type

contains

  function func7() result(res)
    class(v), allocatable :: res
    allocate (res, source = v(3,[10.0,20.0]))
  end function func7

end program test

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2015-02-13 00:00:00         |2015-4-16

--- Comment #8 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
I still see this FAIL for cris-elf on trunk at r222131.  While it is a
regression on trunk and the gcc-5-branch (as mentioned it worked for a brief
period on trunk before the branch), it's not a regression compared to a
release, AFAIK.  I verified that it ICEs also (as described on trunk before the
first fix) on the 4.9-branch.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
The components are deallocated after the containing object.
Draft patch:

Index: trans-expr.c
===================================================================
--- trans-expr.c        (révision 225979)
+++ trans-expr.c        (copie de travail)
@@ -9241,7 +9241,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr
   if (scalar_to_array && dealloc)
     {
       tmp = gfc_deallocate_alloc_comp_no_caf (expr2->ts.u.derived, rse.expr,
0);
-      gfc_add_expr_to_block (&loop.post, tmp);
+      gfc_prepend_expr_to_block (&loop.post, tmp);
     }

   /* When assigning a character function result to a deferred-length variable,
>From gcc-bugs-return-492747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 13:42:23 2015
Return-Path: <gcc-bugs-return-492747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51503 invoked by alias); 18 Jul 2015 13:42:22 -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 51465 invoked by uid 48); 18 Jul 2015 13:42:19 -0000
From: "eugene.zelenko at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66918] Disable "inline function declared but never defined" warning
Date: Sat, 18 Jul 2015 13:42: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: eugene.zelenko 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-66918-4-mpLNxxSgcq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66918-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66918-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/msg01637.txt.bz2
Content-length: 472

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

--- Comment #2 from Eugene Zelenko <eugene.zelenko at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Could you explain why you don't want to have this warning really.  This
> warning is telling you that the inline function is not defined  just like
> static functions.

I want this warning, but I need individual switch to turn it on/off and forcing
it to be warning/error. Just as any other warning.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Yes, this fixes the testsuite failure for me.

For me too.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #6)
> The test has been introduced at revision r220482,

That revision adds interesting comments:

>  /* For a function with a class array result, save the result as
>     a temporary, set the info fields needed by the scalarizer and
>     call the finalization function of the temporary. Note that the
>     nullification of allocatable components needed by the result
>     is done in gfc_trans_assignment_1.  */

and in gfc_trans_assignment_1, there is:

> /* Nullify the allocatable components corresponding to those of the lhs
>    derived type, so that the finalization of the function result does not
>    affect the lhs of the assignment. Prepend is used to ensure that the
>    nullification occurs before the call to the finalizer. 


So, if finalization for derived types with allocatable components means freeing
the allocatable components, the above is more or less a justification for the
patch in comment #9.

What I don't understand is why there is need for two functions
gfc_conv_procedure_call and gfc_trans_assignment_1 doing half of the job, and
why deallocation of components, deallocation of whole allocatable and
finalization are not handled all at once in a single place.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[paul.richard.thomas at gmail dot com]

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

--- Comment #13 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Dear Mikael,

A good principle in general is to assume cock-up, rather than
conspiracy :-) The reason for this spreading between two functions is
incremental development done at very different times. If you can see a
way to rationalize the implementation, please do it.

Many thanks for the patch - assume that it is OK for trunk and 5.x

Paul

On 22 July 2015 at 18:24, mikael at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
>
> --- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
> (In reply to Dominique d'Humieres from comment #6)
>> The test has been introduced at revision r220482,
>
> That revision adds interesting comments:
>
>>  /* For a function with a class array result, save the result as
>>     a temporary, set the info fields needed by the scalarizer and
>>     call the finalization function of the temporary. Note that the
>>     nullification of allocatable components needed by the result
>>     is done in gfc_trans_assignment_1.  */
>
> and in gfc_trans_assignment_1, there is:
>
>> /* Nullify the allocatable components corresponding to those of the lhs
>>    derived type, so that the finalization of the function result does not
>>    affect the lhs of the assignment. Prepend is used to ensure that the
>>    nullification occurs before the call to the finalizer.
>
>
> So, if finalization for derived types with allocatable components means freeing
> the allocatable components, the above is more or less a justification for the
> patch in comment #9.
>
> What I don't understand is why there is need for two functions
> gfc_conv_procedure_call and gfc_trans_assignment_1 doing half of the job, and
> why deallocation of components, deallocation of whole allocatable and
> finalization are not handled all at once in a single place.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to paul.richard.thomas@gmail.com from comment #13)
> A good principle in general is to assume cock-up, rather than
> conspiracy :-) The reason for this spreading between two functions is
> incremental development done at very different times. If you can see a
> way to rationalize the implementation, please do it.
> 
All right.  Well, as a first move, I will just commit the patch. :-)

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

--- Comment #15 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Fri Jul 24 14:44:59 2015
New Revision: 226162

URL: https://gcc.gnu.org/viewcvs?rev=226162&root=gcc&view=rev
Log:
Fix gfortran.dg/class_to_type_4.f90 deallocation code misordering failure

        PR fortran/64986
gcc/fortran/
        * trans-expr.c (gfc_trans_assignment_1): Put component deallocation
        code at the beginning of the block.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

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 #16 from Mikael Morin <mikael at gcc dot gnu.org> ---
I may as well take the bug.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #11)
> > Yes, this fixes the testsuite failure for me.
> 
> For me too.

The patches have been committed.
I assume the problem is fixed now.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[mikael at gcc dot gnu.org]

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

--- Comment #19 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #18)
> The patches have been committed.

I mean the (single) patch has been committed on the two branches.