* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
@ 2021-02-27 23:28 ` dominiq at lps dot ens.fr
2021-03-01 2:46 ` hp at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-02-27 23:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
2021-02-27 23:28 ` [Bug fortran/99307] " dominiq at lps dot ens.fr
@ 2021-03-01 2:46 ` hp at gcc dot gnu.org
2021-03-01 2:52 ` hp at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: hp at gcc dot gnu.org @ 2021-03-01 2:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
2021-02-27 23:28 ` [Bug fortran/99307] " dominiq at lps dot ens.fr
2021-03-01 2:46 ` hp at gcc dot gnu.org
@ 2021-03-01 2:52 ` hp at gcc dot gnu.org
2021-03-01 11:16 ` burnus at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: hp at gcc dot gnu.org @ 2021-03-01 2:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (2 preceding siblings ...)
2021-03-01 2:52 ` hp at gcc dot gnu.org
@ 2021-03-01 11:16 ` burnus at gcc dot gnu.org
2021-03-02 13:25 ` pault at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-03-01 11:16 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (3 preceding siblings ...)
2021-03-01 11:16 ` burnus at gcc dot gnu.org
@ 2021-03-02 13:25 ` pault at gcc dot gnu.org
2021-03-11 18:08 ` [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 " pault at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pault at gcc dot gnu.org @ 2021-03-02 13:25 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (4 preceding siblings ...)
2021-03-02 13:25 ` pault at gcc dot gnu.org
@ 2021-03-11 18:08 ` pault at gcc dot gnu.org
2021-03-12 10:42 ` dominiq at lps dot ens.fr
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pault at gcc dot gnu.org @ 2021-03-11 18:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (5 preceding siblings ...)
2021-03-11 18:08 ` [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 " pault at gcc dot gnu.org
@ 2021-03-12 10:42 ` dominiq at lps dot ens.fr
2021-04-13 14:08 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-12 10:42 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (6 preceding siblings ...)
2021-03-12 10:42 ` dominiq at lps dot ens.fr
@ 2021-04-13 14:08 ` rguenth at gcc dot gnu.org
2021-04-13 14:10 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-13 14:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (7 preceding siblings ...)
2021-04-13 14:08 ` rguenth at gcc dot gnu.org
@ 2021-04-13 14:10 ` rguenth at gcc dot gnu.org
2021-04-13 14:11 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-13 14:10 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (8 preceding siblings ...)
2021-04-13 14:10 ` rguenth at gcc dot gnu.org
@ 2021-04-13 14:11 ` rguenth at gcc dot gnu.org
2021-04-13 15:57 ` pault at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-13 14:11 UTC (permalink / raw)
To: gcc-bugs
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)
...
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (9 preceding siblings ...)
2021-04-13 14:11 ` rguenth at gcc dot gnu.org
@ 2021-04-13 15:57 ` pault at gcc dot gnu.org
2021-04-15 6:34 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pault at gcc dot gnu.org @ 2021-04-13 15:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (10 preceding siblings ...)
2021-04-13 15:57 ` pault at gcc dot gnu.org
@ 2021-04-15 6:34 ` cvs-commit at gcc dot gnu.org
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-15 6:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (11 preceding siblings ...)
2021-04-15 6:34 ` cvs-commit at gcc dot gnu.org
@ 2021-05-04 12:32 ` rguenth at gcc dot gnu.org
2022-04-21 17:05 ` mikael at gcc dot gnu.org
2022-07-05 19:03 ` danglin at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (12 preceding siblings ...)
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
@ 2022-04-21 17:05 ` mikael at gcc dot gnu.org
2022-07-05 19:03 ` danglin at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: mikael at gcc dot gnu.org @ 2022-04-21 17:05 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
2021-02-27 23:23 [Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test danglin at gcc dot gnu.org
` (13 preceding siblings ...)
2022-04-21 17:05 ` mikael at gcc dot gnu.org
@ 2022-07-05 19:03 ` danglin at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: danglin at gcc dot gnu.org @ 2022-07-05 19:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread