[Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

            Bug ID: 99307
           Summary: FAIL: gfortran.dg/class_assign_4.f90   -O0  execution
                    test
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
              Host: hppa-unknown-linux-gnu
            Target: hppa-unknown-linux-gnu
             Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../gfo
rtran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../
-B/home/dave/gn
u/gcc/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/class_assign_4.f90 -fdiagnostics-plain-output
-fdiagnostics-plain-ou
tput -O0 -pedantic-errors
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortr
an/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/
dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objd
ir/hppa-linux-gnu/./libatomic/.libs -lm -o ./class_assign_4.exe
PASS: gfortran.dg/class_assign_4.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfort
ran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/
testsuite/gfortran1/../..:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortr
an/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave
/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/t
estsuite/gfortran1/../..:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
Execution timeout is: 300
spawn [open ...]
corrupted size vs. prev_size

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
FAIL: gfortran.dg/class_assign_4.f90   -O0  execution test

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-27
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Also seen on Darwin; the runtime error is

a.out(22702,0x10db51e00) malloc: Incorrect checksum for freed object
0x7ff344406fc0: probably modified after being freed.
Corrupt value: 0x41f0000000000007
a.out(22702,0x10db51e00) malloc: *** set a breakpoint in malloc_error_break to
debug

Program received signal SIGABRT: Process abort signal.

Reduced test

module m
  implicit none
  type :: t1
    integer :: i
  CONTAINS
  end type
  type, extends(t1) :: t2
    real :: r
  end type

  interface operator(+)
    module procedure add_t1
  end interface

contains
  function add_t1 (a, b) result (c)
    class(t1), intent(in) :: a(:), b(:)
    class(t1), allocatable :: c(:)
    allocate (c, source = a)
    c%i = a%i + b%i
    select type (c)
      type is (t2)
      select type (b)
        type is (t2)
          c%r = c%r + b%r
      end select
    end select
  end function add_t1

end module m

subroutine test_t1
  use m
  implicit none

  class(t1), dimension(:), allocatable :: x, y

  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]
  y = x
  x = realloc_t1 (y)
  x = realloc_t1 (x)
  x = x(3:1:-1) + y
  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]

contains

  function realloc_t1 (arg) result (res)
    class(t1), dimension(:), allocatable :: arg
    class(t1), dimension(:), allocatable :: res
    select type (arg)
      type is (t2)
        allocate (res, source = [t1 (arg(3)%i), t1 (arg(2)%i), t1 (arg(1)%i)])
      type is (t1)
        allocate (res, source = [t1 (arg(2)%i), t1 (arg(1)%i), t1 (arg(3)%i)])
    end select
  end function realloc_t1

end subroutine test_t1

  call test_t1
end

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[hp at gcc dot gnu.org]

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

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

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

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #0)
> FAIL: gfortran.dg/class_assign_4.f90   -O0  execution test

According to
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661332.html
the test fails execution at *all* tested optimization levels, not just -O0.

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[hp at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
               Host|hppa-unknown-linux-gnu      |
             Target|hppa-unknown-linux-gnu      |hppa-unknown-linux-gnu,
                   |                            |cris-elf,
                   |                            |sparcv9-sun-solaris2.11,
                   |                            |x86_64-pc-solaris2.11
              Build|hppa-unknown-linux-gnu      |

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
I was about to enter a bug-report with the following contents, most of which is
not redundant:

Since the commit 29a5298955f7 / r11-7349 "Fortran: Fix for class
defined operators [PR99124].", class_assign_4 has failed at
execution for cris-elf, at all optimization levels.

I see the same goes for some solaris targets:

sparcv9-sun-solaris2.11
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661993.html

and x86_64-pc-solaris2.11
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661992.html

but apparently none of the other posted test-results I checked.

Looking into a trace for cris-elf, I see a call to "free" hits
an invalid memory access (the equivalent of SEGV) and the
execution terminates.  This hints at invalid memory management
related to the allocations done in that test, like too short
allocation or write-after-free.

For a native x86_64-linux build, valgrind does complain when
applied to the test, but as my valgrind isn't dwarf-5-aware, I
can't see much besides and can't be too sure besides the
relation to memory allocation.  Here are the first four valgrind
indications for the test as compiled at -O0 (and adding
-gdwarf-2 to the build flags):

==32498== Invalid write of size 8
==32498==    at 0x4C32643: memmove (vg_replace_strmem.c:1252)
==32498==    by 0x4076F8: test_t1_ (class_assign_4.f90:62)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==  Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd
==32498==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498==    by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid read of size 4
==32498==    at 0x40507B: check_t1.2 (class_assign_4.f90:104)
==32498==    by 0x407878: test_t1_ (class_assign_4.f90:63)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==  Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd
==32498==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498==    by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid write of size 8
==32498==    at 0x407BE8: test_t1_ (class_assign_4.f90:66)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==  Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd
==32498==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498==    by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid read of size 8
==32498==    at 0x400886: __m_MOD___copy_m_T2 (class_assign_4.f90:38)
==32498==    by 0x407EBF: test_t1_ (class_assign_4.f90:67)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)
==32498==  Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd
==32498==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498==    by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498==    by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498==    by 0x409EA5: main (class_assign_4.f90:185)

I'm guessing there's a flaw with the test, but I don't know
fortran so unfortunately I can't debug it.

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #1)
> Reduced test

While -fsanitize=address,undefined does not find anything on x86_64-gnu-linux,
I do see with valgrind:

==98347== Invalid write of size 8
==98347==    at 0x40397E: test_t1_ (ijd.f90:43)
==98347==    by 0x403A4E: MAIN__ (ijd.f90:60)
==98347==    by 0x403A85: main (ijd.f90:61)
==98347==  Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd
==98347==    at 0x483DFAF: realloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==98347==    by 0x402A6D: test_t1_ (ijd.f90:40)
==98347==    by 0x403A4E: MAIN__ (ijd.f90:60)
==98347==    by 0x403A85: main (ijd.f90:61)

That's:
  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]
  y = x
  x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12
  x = realloc_t1 (x)
  x = x(3:1:-1) + y
  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of size 8

Looking at the Fortran code,
  x and y have the dynamic type T2 until 'realloc_t1', which turns this into
the dynamic type T1.

In the last line (line 43), the dynamic type changes again to T2.

In terms of memory usage: 3*8bytes before the first realloc_t1 call, then
3*4bytes and for the last line again 3*8bytes.

 * * *

It seems as if the reallocation does not work properly if the dynamic type
changes – at least not if the required size increased in the assignment. (The
valgrind message implies that shrinking did work in line 40.)

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
> (In reply to Dominique d'Humieres from comment #1)
> > Reduced test
> 
> While -fsanitize=address,undefined does not find anything on
> x86_64-gnu-linux, I do see with valgrind:
> 
> ==98347== Invalid write of size 8
> ==98347==    at 0x40397E: test_t1_ (ijd.f90:43)
> ==98347==    by 0x403A4E: MAIN__ (ijd.f90:60)
> ==98347==    by 0x403A85: main (ijd.f90:61)
> ==98347==  Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd
> ==98347==    at 0x483DFAF: realloc (in
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==98347==    by 0x402A6D: test_t1_ (ijd.f90:40)
> ==98347==    by 0x403A4E: MAIN__ (ijd.f90:60)
> ==98347==    by 0x403A85: main (ijd.f90:61)
> 
> That's:
>   x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]
>   y = x
>   x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12
>   x = realloc_t1 (x)
>   x = x(3:1:-1) + y
>   x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of
> size 8
> 
> Looking at the Fortran code,
>   x and y have the dynamic type T2 until 'realloc_t1', which turns this into
> the dynamic type T1.
> 
> In the last line (line 43), the dynamic type changes again to T2.
> 
> In terms of memory usage: 3*8bytes before the first realloc_t1 call, then
> 3*4bytes and for the last line again 3*8bytes.
> 
>  * * *
> 
> It seems as if the reallocation does not work properly if the dynamic type
> changes – at least not if the required size increased in the assignment.
> (The valgrind message implies that shrinking did work in line 40.)

I am unable to see why this is happening. The valgrind complaints go away if a
different array size is assigned before the changes in type. For some reason,
it seems that the vptr->size is not being read correctly or is never set.

Paul

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[pault at gcc dot gnu.org]

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

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

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 50368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50368&action=edit
A fix and more for the PR

The chunk: @@ -10274,23 +10309,10 @@ gfc_alloc_allocatable_for_assignment fixes
the PR. The rest gets rid of all(?) array references of class objects since the
casting was always a problem.

Cheers

Paul

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The patch works for me. Thanks!

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |10.3.1

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The problem also appears on the GCC 10 branch.

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 99796 has been marked as a duplicate of this bug. ***

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Using valgrind on the testcase makes the problem easier to trigger.

> valgrind ./class_assign_4.exe 
==4208== Memcheck, a memory error detector
==4208== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4208== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4208== Command: ./class_assign_4.exe
==4208== 
==4208== Invalid write of size 8
==4208==    at 0x4C35863: memmove (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4208==    by 0x4076A7: test_t1_ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409DEF: MAIN__ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409E2B: main (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==  Address 0x5e47bd8 is 8 bytes inside a block of size 12 alloc'd
==4208==    at 0x4C308BF: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4208==    by 0x405C3C: test_t1_ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409DEF: MAIN__ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409E2B: main (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208== 
==4208== Invalid read of size 4
==4208==    at 0x405048: check_t1.2 (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x407822: test_t1_ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409DEF: MAIN__ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409E2B: main (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==  Address 0x5e47be0 is 4 bytes after a block of size 12 alloc'd
==4208==    at 0x4C308BF: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4208==    by 0x405C3C: test_t1_ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
==4208==    by 0x409DEF: MAIN__ (in
/home/rguenther/obj-gcc10-g/gcc/class_assign_4.exe)
...

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas <pault at gcc dot gnu.org> ---
The patch was posted at
https://gcc.gnu.org/pipermail/fortran/2021-April/055923.html

I'll ping it.

Thanks Richard.

Paul

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:9a0e09f3dd5339bb18cc47317f2298d9157ced29

commit r11-8187-g9a0e09f3dd5339bb18cc47317f2298d9157ced29
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Thu Apr 15 07:34:26 2021 +0100

    Fortran: Fix class reallocate on assignment [PR99307].

    2021-04-15  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/99307
            * symbol.c: Remove trailing white space.
            * trans-array.c (gfc_trans_create_temp_array): Create a class
            temporary for class expressions and assign the new descriptor
            to the data field.
            (build_class_array_ref): If the class expr can be extracted,
            then use that for 'decl'. Class function results are reliably
            handled this way. Call gfc_find_and_cut_at_last_class_ref to
            eliminate largely redundant code. Remove dead code and recast
            the rest of the code to extract 'decl' for remaining cases.
            Call gfc_build_spanned_array_ref.
            (gfc_alloc_allocatable_for_assignment): Use class descriptor
            element length for 'elemsize1'. Eliminate repeat set of dtype
            for class expressions.
            * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Include
            additional code from build_class_array_ref, and use optional
            gfc_typespec pointer argument.
            (gfc_trans_scalar_assign): Make use of pre and post blocks for
            all class expressions.
            * trans.c (get_array_span): For unlimited polymorphic exprs
            multiply the span by the value of the _len field.
            (gfc_build_spanned_array_ref): New function.
            (gfc_build_array_ref): Call gfc_build_spanned_array_ref and
            eliminate repeated code.
            * trans.h: Add arg to gfc_find_and_cut_at_last_class_ref and
            add prototype for gfc_build_spanned_array_ref.

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed?

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

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

--- Comment #14 from John David Anglin <danglin at gcc dot gnu.org> ---
Yes.