User account creation filtered due to spam.
On Linux/x86-64, r208641 caused: FAIL: gfortran.dg/assumed_rank_7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/assumed_rank_7.f90 -O3 -fomit-frame-pointer -funroll-loops execution test with -march=corei7: Core was generated by `./assumed_rank_7.exe'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000003cddb47859 in __memcpy_ssse3_back () from /lib64/libc.so.6 (gdb) bt #0 0x0000003cddb47859 in __memcpy_ssse3_back () from /lib64/libc.so.6 #1 0x00000000004010d2 in MAIN__ () #2 0x00000000004009ed in main () (gdb) 0x0000003cddb47856 <+182>: add %rdx,%rsi => 0x0000003cddb47859 <+185>: movdqu -0x10(%rsi),%xmm0 0x0000003cddb4785e <+190>: lea -0x10(%rdi),%r8 (gdb) p/x $rsi $5 = 0x602040 (gdb) It only happens when running make check-gfortran RUNTESTFLAGS="dg.exp=assumed_rank_7.f90 --target_board='unix{-march=corei7\ -fno-backtrace}'" with [hjl@gnu-mic-2 gfortran.dg]$ cat /proc/sys/kernel/randomize_va_space 2 [hjl@gnu-mic-2 gfortran.dg]$ Gfortran generates: movl $168, %edx ^^^ Copy 168 bytes movl $at.2415+24, %esi ^^ Start at at.2415 + 24 movq at.2415(%rip), %r8 movq at.2415+8(%rip), %r9 leaq 40(%rsp), %rdi movq $__vtab_MAIN___T.2395, 208(%rsp) movq at.2415+16(%rip), %r10 movq %r8, 16(%rsp) movq %r9, 24(%rsp) movq %r10, 32(%rsp) call memcpy ... .local at.2415 .comm at.2415,72,64 ^^ 72 bytes Write 168 bytes to (72 - 24) bytes leads to segfault.
I can't reproduce it, in any case, this seems to have been broken before as well and starting with 208668 I get valgrind error about memcpy with overlapping arguments. The bug seems in: class.5._data.dim[0 ...] = at.dim[0 ...]; at apparently has dim FIELD_DECL as array of 2 (24-byte) structs, i.e. 48 bytes long, while the ARRAY_RANGE_REF around it accesses 7 24-byte structs, i.e. 168 bytes.
at's dim array is created by: #6 0x00000000006fc242 in gfc_get_array_descriptor_base (dimen=2, codimen=0, restricted=true, akind=GFC_ARRAY_ALLOCATABLE) at ../../gcc/fortran/trans-types.c:1754 where the dimen=2 causes the dim array to be sized with 2 elements only, while the larger ARRAY_REF comes from: #4 0x0000000000e58b85 in build4_stat (code=ARRAY_RANGE_REF, tt=<array_type 0x7ffff19f0540>, arg0=<component_ref 0x7ffff1a08510>, arg1=<integer_cst 0x7ffff18afa00>, arg2=<tree 0x0>, arg3=<tree 0x0>) at ../../gcc/tree.c:4241 #5 0x00000000006a8a72 in build4_stat_loc (loc=2692, code=ARRAY_RANGE_REF, type=<array_type 0x7ffff19f0540>, arg0=<component_ref 0x7ffff1a08510>, arg1=<integer_cst 0x7ffff18afa00>, arg2=<tree 0x0>, arg3=<tree 0x0>) at ../../gcc/tree.h:3499 #6 0x00000000006a98ff in class_array_data_assign (block=0x7fffffffd810, lhs_desc=<component_ref 0x7ffff1a08390>, rhs_desc=<var_decl 0x7ffff1a052f8 at>, lhs_type=true) at ../../gcc/fortran/trans-expr.c:318 #7 0x00000000006a9ef5 in gfc_conv_derived_to_class (parmse=0x7fffffffd9a0, e=0x1cd0640, class_ts=..., vptr=<tree 0x0>, optional=false, optional_alloc_ptr=false) at ../../gcc/fortran/trans-expr.c:427 #8 0x00000000006b3d51 in gfc_conv_procedure_call (se=0x7fffffffdbe0, sym=0x1ccc570, args=0x1c63760, expr=0x0, append_args=0x0) at ../../gcc/fortran/trans-expr.c:4039 The bug is in there already in r189800: ./f951.189800 -quiet -O2 assumed_rank_7.f90 -mstringop-strategy=libcall; gfortran -o assumed_rank_7{,.s}; valgrind ./assumed_rank_7; echo $? ==7529== Memcheck, a memory error detector ==7529== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==7529== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==7529== Command: ./assumed_rank_7 ==7529== ==7529== Source and destination overlap in memcpy(0xfff0001b8, 0xfff000168, 168) ==7529== at 0x4A0A403: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7529== by 0x400F5B: MAIN__ (in /usr/src/gcc-test/obj/gcc/assumed_rank_7) ==7529== by 0x4007AC: main (in /usr/src/gcc-test/obj/gcc/assumed_rank_7) and r189600 still rejected this code, so to me this doesn't look like a regression, but miscompilation from the day one when this particular feature has been enabled.
Running the test compiled with -fsanitize=address gives ================================================================= ==70806==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff58110428 at pc 0x107b115d8 bp 0x7fff58110240 sp 0x7fff58110218 READ of size 168 at 0x7fff58110428 thread T0 #0 0x107b115d7 (/opt/gcc/gcc4.9w/lib/libasan.1.dylib+0x1a5d7) #1 0x107af0340 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001340) #2 0x107af18ad (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000028ad) #3 0x7fff9184e5fc (/usr/lib/system/libdyld.dylib+0x35fc) #4 0x0 Address 0x7fff58110428 is located in stack of thread T0 at offset 104 in frame #0 0x107af000d (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10000100d) This frame has 1 object(s): [32, 104) 'at' <== Memory access at offset 104 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x1fffeb022030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb022040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb022050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb022060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb022070: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 =>0x1fffeb022080: 00 00 00 00 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00 0x1fffeb022090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0220a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0220b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0220c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0220d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==70806==ABORTING
BTW, I'm also getting: +FAIL: gfortran.dg/ichar_3.f90 -O (internal compiler error) +FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors) +FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (internal compiler error) +FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (test for excess errors) when f951 is built with -fstack-protector, again, doesn't look like a recent regression, at some point this ICEd, at other points it needs -fstack-protector, -D_FORTIFY_SOURCE, valgrind or asan.
Cannot reproduce here; maybe this works? diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 1e156ff..f3423de 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -424,7 +424,7 @@ gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e, gfc_conv_expr_descriptor (parmse, e); if (e->rank != class_ts.u.derived->components->as->rank) - class_array_data_assign (&block, ctree, parmse->expr, true); + class_array_data_assign (&block, ctree, parmse->expr, false); else { if (gfc_expr_attr (e).codimension)
H.J. just filed a separate PR about the ichar_3.f90 failure in PR60678.
(In reply to Jakub Jelinek from comment #6) > H.J. just filed a separate PR about the ichar_3.f90 failure in PR60678. And one at PR 60677, which is due to the same cause. (The issue is there that one has a len=1 character argument and a kind, but the BT_CHARACTER leads to an extra length argument, which exceeds an array bound expecting only two arguments.)
Author: burnus Date: Fri Mar 28 20:04:01 2014 New Revision: 208918 URL: http://gcc.gnu.org/viewcvs?rev=208918&root=gcc&view=rev Log: 2014-03-28 Mikael Morin <mikael@gcc.gnu.org> Tobias Burnus <burnus@net-b.de> PR fortran/ * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
Author: burnus Revision: 208918 Modified property: svn:log Modified: svn:log at Fri Mar 28 20:34:48 2014 ------------------------------------------------------------------------------ --- svn:log (original) +++ svn:log Fri Mar 28 20:34:48 2014 @@ -1,7 +1,7 @@ 2014-03-28 Mikael Morin <mikael@gcc.gnu.org> Tobias Burnus <burnus@net-b.de> - PR fortran/ + PR fortran/60576 * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr.
Author: burnus Date: Fri Mar 28 20:56:28 2014 New Revision: 208923 URL: http://gcc.gnu.org/viewcvs?rev=208923&root=gcc&view=rev Log: 2014-03-28 Mikael Morin <mikael@gcc.gnu.org> Tobias Burnus <burnus@net-b.de> PR fortran/60576 * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c
(In reply to H.J. Lu from comment #0) > It only happens when running > make check-gfortran RUNTESTFLAGS="dg.exp=assumed_rank_7.f90 > --target_board='unix{-march=corei7\ -fno-backtrace}'" Can you confirm that it is now fixed? Not that we only fixed part of the problem.
(In reply to Tobias Burnus from comment #11) > (In reply to H.J. Lu from comment #0) > > It only happens when running > > make check-gfortran RUNTESTFLAGS="dg.exp=assumed_rank_7.f90 > > --target_board='unix{-march=corei7\ -fno-backtrace}'" > > Can you confirm that it is now fixed? Not that we only fixed part of the > problem. gfortran.dg/assumed_rank_7.f90 has been changed by r208668 and I can't reproduce it anymore.
(In reply to H.J. Lu from comment #12) > gfortran.dg/assumed_rank_7.f90 has been changed by r208668 > and I can't reproduce it anymore. I close it as FIXED and hope the best.
gfortran.dg/assumed_rank_7.f90 still aborts when compiled with -fsanitize=address as in comment 3.
Reduced test case failing on x86_64-apple-darwin13 r208927 with -m64 (4.9.0 and 4.8.3, it succeeds with -m32 as well as the original test). [Book15] f90/bug% cat assumed_rank_7_red.f90 implicit none type t integer :: i end type class(T), allocatable :: ac(:,:) type(T), allocatable :: at(:,:) allocate(ac(2:3,2:4)) allocate(at(2:3,2:4)) call bar(ac) contains subroutine bar(x) type(t) :: x(..) call foo(x) end subroutine subroutine foo(x) class(t) :: x(..) end subroutine end [Book15] f90/bug% gfc assumed_rank_7_red.f90 -fsanitize=address [Book15] f90/bug% a.out ================================================================= ==40254==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff587043c0 at pc 0x10751d678 bp 0x7fff58704230 sp 0x7fff58704208 READ of size 192 at 0x7fff587043c0 thread T0 #0 0x10751d677 (/opt/gcc/gcc4.9w/lib/libasan.1.dylib+0x1a677) #1 0x1074fc968 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001968) #2 0x1074fc6c7 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000016c7) #3 0x1074fc9af (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000019af) #4 0x7fff960745fc (/usr/lib/system/libdyld.dylib+0x35fc) #5 0x0 Address 0x7fff587043c0 is located in stack of thread T0 at offset 0 in frame #0 0x1074fc1fe (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000011fe) This frame has 1 object(s): [32, 104) 'at' <== Memory access at offset 0 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow ??:0 ?? Shadow bytes around the buggy address: 0x1fffeb0e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1fffeb0e0870: 00 00 00 00 00 00 00 00[f1]f1 f1 f1 00 00 00 00 0x1fffeb0e0880: 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 0x1fffeb0e0890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==40254==ABORTING The code executes without error if I comment the line allocate(at(2:3,2:4))
(In reply to Dominique d'Humieres from comment #14) > gfortran.dg/assumed_rank_7.f90 still aborts when compiled with > -fsanitize=address as in comment 3. Reopening then.
GCC 4.8.3 is being released, adjusting target milestone.
Still failing at r218570: [Book15] f90/bug% gfcp assumed_rank_7_red.f90 -fsanitize=address -g [Book15] f90/bug% a.out ================================================================= ==65593==ERROR: AddressSanitizer: unknown-crash on address 0x7fff5e78d250 at pc 0x00010147392a bp 0x7fff5e78d0f0 sp 0x7fff5e78d0e8 READ of size 192 at 0x7fff5e78d250 thread T0 #0 0x101473929 in bar.3416 /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/assumed_rank_7_red.f90:17 #1 0x101473618 in MAIN__ /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/assumed_rank_7_red.f90:12 #2 0x10147399d in main /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/assumed_rank_7_red.f90:12 #3 0x7fff8451b5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8) #4 0x0 (<unknown module>) Address 0x7fff5e78d250 is located in stack of thread T0 SUMMARY: AddressSanitizer: unknown-crash /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/assumed_rank_7_red.f90:17 bar.3416 ...
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed