[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- [...] > I've just applied the patch to trunk, rebuilt f951 on > sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test > now PASSes for both 32 and 64-bit. > > I'll include the patch in tonight's bootstrap and let you know if there > are any problems elsewhere. There weren't any in last night's sparc-sun-solaris2.11 bootstrap: both 32 and 64-bit unlimited_polymorphic_30.f03 failures are gone. Thanks. Rainer
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Paul Thomas --- > Created attachment 46216 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216&action=edit > Patch for the remaining problems. > > I am registering this now as a measure of progress towards doing a proper job > of fixing this PR for good. I've just applied the patch to trunk, rebuilt f951 on sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test now PASSes for both 32 and 64-bit. I'll include the patch in tonight's bootstrap and let you know if there are any problems elsewhere.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #17 from Paul Thomas --- Created attachment 46216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216&action=edit Patch for the remaining problems. I am registering this now as a measure of progress towards doing a proper job of fixing this PR for good. The part in trans-expr.c(gfc_trans_assignment_1) is obligatory and stops the compiler doubling up mallocs on top of one another. The part in trans-array.c(gfc_alloc_allocatable_for_assignment) is a partial solution. Instead of testing the shape of the lhs against that of that of the rhs, we need to be comparing the size in bytes. The attached lets the system do this by relying on realloc to do the job. This might be the most efficient way to do it - I will look into it. I note in passing that the estimate of the size of the rhs is going to fail, where class entities are a dynamic type other than the declared type. This is easily done and requires perspiration rather than inspiration :-) Paul
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #16 from Dominique d'Humieres --- Compiling the reduced test type :: any_vector class(*), allocatable :: v(:) end type type(any_vector) :: x, y x%v = ['foo','bar'] end with -fsanitize=address gives ==54286==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200150 at pc 0x000102fb38df bp 0x7ffeecc4d180 sp 0x7ffeecc4d178 READ of size 8 at 0x60200150 thread T0 #0 0x102fb38de in MAIN__ (a.out:x86_64+0x118de) #1 0x102fb3b9a in main (a.out:x86_64+0x11b9a) #2 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8) 0x60200156 is located 0 bytes to the right of 6-byte region [0x60200150,0x60200156) allocated by thread T0 here: #0 0x1032e784f in wrap_malloc sanitizer_malloc_mac.inc:114 #1 0x102fb37b3 in MAIN__ (a.out:x86_64+0x117b3) #2 0x102fb3b9a in main (a.out:x86_64+0x11b9a) #3 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8) SUMMARY: AddressSanitizer: heap-buffer-overflow (a.out:x86_64+0x118de) in MAIN__ Shadow bytes around the buggy address: 0x1c03ffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c03ffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c03fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c04: fa fa fd fd fa fa fd fd fa fa 00 00 fa fa 00 07 0x1c040010: fa fa 03 fa fa fa 00 00 fa fa 00 06 fa fa 06 fa =>0x1c040020: fa fa 07 fa fa fa 07 fa fa fa[06]fa fa fa fa fa 0x1c040030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #15 from Eric Botcazou --- This seems totally broken on x86-64 too, see valgrind: eric@polaris:~> valgrind ./unlimited_polymorphic_30 ==42237== Memcheck, a memory error detector ==42237== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==42237== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==42237== Command: ./unlimited_polymorphic_30 ==42237== ==42237== Conditional jump or move depends on uninitialised value(s) ==42237==at 0x4013C7: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Invalid write of size 8 ==42237==at 0x40142B: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== Address 0x5768ac0 is 0 bytes inside a block of size 6 alloc'd ==42237==at 0x4C2A0B0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==42237==by 0x401333: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Conditional jump or move depends on uninitialised value(s) ==42237==at 0x401465: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Invalid read of size 8 ==42237==at 0x4013C1: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== Address 0x5768ac3 is 3 bytes inside a block of size 6 alloc'd ==42237==at 0x4C2A0B0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==42237==by 0x401333: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Conditional jump or move depends on uninitialised value(s) ==42237==at 0x401A6D: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Invalid read of size 8 ==42237==at 0x401A67: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== Address 0x5768ac4 is 4 bytes inside a block of size 6 alloc'd ==42237==at 0x4C2A0B0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==42237==by 0x401333: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Invalid write of size 4 ==42237==at 0x4011DC: __copy_INTEGER_4_.3853 (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x401B54: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== Address 0x5768ac4 is 4 bytes inside a block of size 6 alloc'd ==42237==at 0x4C2A0B0: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==42237==by 0x401333: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Conditional jump or move depends on uninitialised value(s) ==42237==at 0x4022FC: foo.3898 (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x401B73: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) ==42237== ==42237== Conditional jump or move depends on uninitialised value(s) ==42237==at 0x4022FC: foo.3898 (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x401F42: MAIN__ (in /home/eric/unlimited_polymorphic_30) ==42237==by 0x4023E6: main (in /home/eric/unlimited_polymorphic_30) In particular: x.v._data.data = (void * restrict) __builtin_malloc (6); D.1053 = (void *[0:] * restrict) x.v._data.data; *((void * *) D.1053 + (sizetype) (((S.8 + D.1059) + D.1054) * (x.v._vptr->_size * MAX_EXPR ))) = __builtin_malloc (MAX_EXPR <(unsigned long) x.v._vptr->_size, 1>); The second call to __builtin_malloc overwrites part of the address returned by the first call (or yields SIGBUS on the SPARC). There might be some confusion about pointer arithmetics in the GENERIC code.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |7.5
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Paul Thomas --- [...] > Does the attachment fix the problem? Seems I completely missed this, sorry. I've just ran sparc-sun-solaris2.11 and i386-pc-solaris2.11 bootstraps last night; unfortunately there was no change with your patch. Rainer
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #13 from Paul Thomas --- Created attachment 44356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44356&action=edit Fix for the new problem? Hi Rainer, Does the attachment fix the problem? Cheers Paul
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #12 from Rainer Orth --- The new testcase FAILs on Solaris/SPARC on trunk, gcc-7 and gcc-8 branches: 32-bit sparc: +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O0 execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O1 execution test 64-bit sparc also: +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O2 execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -g execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -Os execution test On gcc-testresults, there are also reports on hppa2.0w-hp-hpux11.11, spu-unknown-elf. The tests FAIL like this: Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: gdb shows Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00011244 in MAIN__ () at /vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13 13x%v = ['foo','bar'] (gdb) where #0 0x00011244 in MAIN__ () at /vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13 1: x/i $pc => 0x11244 :ld [ %g1 ], %g1 (gdb) p/x $g1 $1 = 0x22a4b i.e. an unaligned access.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- Fixed on 7-, 8- and 9-branches. Thanks for the report. Paul
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #10 from Paul Thomas --- Author: pault Date: Mon Jun 25 07:52:09 2018 New Revision: 262005 URL: https://gcc.gnu.org/viewcvs?rev=262005&root=gcc&view=rev Log: 2018-06-25 Paul Thomas PR fortran/83118 Back port from trunk * resolve.c (resolve_ordinary_assign): Force the creation of a vtable for assignment of non-polymorphic expressions to an unlimited polymorphic object. * trans-array.c (gfc_alloc_allocatable_for_assignment): Use the size of the rhs type for such assignments. Set the dtype, _len and vptrs appropriately. * trans-expr.c (gfc_trans_assignment): Force the use of the _copy function for these assignments. 2018-06-25 Paul Thomas PR fortran/83118 Back port from trunk * gfortran.dg/unlimited_polymorphic_30.f03: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/fortran/trans-array.c branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #9 from Paul Thomas --- Author: pault Date: Mon Jun 25 07:49:27 2018 New Revision: 262004 URL: https://gcc.gnu.org/viewcvs?rev=262004&root=gcc&view=rev Log: 2018-06-25 Paul Thomas PR fortran/83118 Back port from trunk * resolve.c (resolve_ordinary_assign): Force the creation of a vtable for assignment of non-polymorphic expressions to an unlimited polymorphic object. * trans-array.c (gfc_alloc_allocatable_for_assignment): Use the size of the rhs type for such assignments. Set the dtype, _len and vptrs appropriately. * trans-expr.c (gfc_trans_assignment): Force the use of the _copy function for these assignments. 2018-06-25 Paul Thomas PR fortran/83118 Back port from trunk * gfortran.dg/unlimited_polymorphic_30.f03: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #8 from Paul Thomas --- Author: pault Date: Thu Jun 21 17:34:31 2018 New Revision: 261857 URL: https://gcc.gnu.org/viewcvs?rev=261857&root=gcc&view=rev Log: 2018-06-21 Paul Thomas PR fortran/83118 * resolve.c (resolve_ordinary_assign): Force the creation of a vtable for assignment of non-polymorphic expressions to an unlimited polymorphic object. * trans-array.c (gfc_alloc_allocatable_for_assignment): Use the size of the rhs type for such assignments. Set the dtype, _len and vptrs appropriately. * trans-expr.c (gfc_trans_assignment): Force the use of the _copy function for these assignments. 2018-06-21 Paul Thomas PR fortran/83118 * gfortran.dg/unlimited_polymorphic_30.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #7 from Paul Thomas --- Created attachment 44306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44306&action=edit Patch for comment #6.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
Neil Carlson changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE |---
--- Comment #6 from Neil Carlson ---
It doesn't fix the test case of comment 4 (which I only gave as a mod to the
comment 0 example). Here it is explicitly:
type :: any_vector
class(*), allocatable :: v(:)
end type
type(any_vector) :: x, y
x%v = ['foo','bar']
select type (v => x%v)
type is (character(*))
print '("orig=[""",a,''","'',a,''"]'')', v ! expect orig=["foo","bar"]
end select
y = x ! THIS ASSIGNMENT IS NOT BEING DONE CORRECTLY
select type (v => y%v)
type is (character(*))
print '("copy=[""",a,''","'',a,''"]'')', v ! expect copy=["foo","bar"]
end select
end
$ gfortran --version
GNU Fortran (GCC) 8.1.1 20180521
$ gfortran gfortran-20171122b.f90
$ ./a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f249667794f in ???
#1 0x0 in ???
Segmentation fault (core dumped)
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |DUPLICATE Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- This bug is fixed by the patch for PR84546, which has already been applied to 8-branch and trunk. I am just now regtesting on 7-branch and intend to commit on success. Paul *** This bug has been marked as a duplicate of bug 84546 ***
