From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19600 invoked by alias); 17 Feb 2014 08:17:43 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 19438 invoked by uid 48); 17 Feb 2014 08:17:39 -0000 From: "bernd.edlinger at hotmail dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7 Date: Mon, 17 Feb 2014 08:17: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: X-Bugzilla-Severity: normal X-Bugzilla-Who: bernd.edlinger at hotmail dot de X-Bugzilla-Status: NEW 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: In-Reply-To: References: 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: 2014-02/txt/msg01630.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #8 from Bernd Edlinger --- (In reply to janus from comment #5) > (In reply to Bernd Edlinger from comment #3) > > > The function "make_real" is not invoked directly, but through the type-bound > > > "a%real", which is called three times in the test case. Does the failure > > > occur already at the first one (i.e. line 67)? Can you give a reduced test > > > case? > > > > Yes it is in line 67. > > Ok, then I guess the following reduction should be enough to trigger the bug? > > > module m > > type :: t1 > integer :: i = 42 > contains > procedure, pass :: real => make_real > end type > > contains > > real function make_real (arg) > class(t1), intent(in) :: arg > make_real = real (arg%i) > end function make_real > > end module m > > use m > class(t1), pointer :: a > type(t1), target :: b > a => b > if (a%real() .ne. real (42)) call abort > end > > The crash occurs if I add the line "procedure(make_real), pointer :: ptr" to type t1. > Additionally you could try if calling 'make_real' directly (without the > type-binding) works, i.e. replace the last line by: > > if (make_real(a) .ne. real (42)) call abort > > This line does not abort. > > > The type-bound call is transformed into a procedure-pointer-component > > > call, i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work > > > on ARMv7? > > > > Yes, the test cases that failed with the last snapshot are: > > > > FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 execution test > > FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 execution test > > FAIL: gfortran.dg/select_type_4.f90 -O2 execution test > > This one might possibly be related. It also involves polymorphism (but no > type-bound procedures). I think dynamic_dispatch_3.f03 duplicates this one. But I am not sure about select_type_4.f90: $ gfortran -O1 -g select_type_4.f90 -o select_type_4 $ ./select_type_4 1.23000002 42 Node with no data. Some other node type. 4.55999994 $ gfortran -O2 -g select_type_4.f90 -o select_type_4 $ ./select_type_4 1.23000002 42 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation fault Program received signal SIGSEGV, Segmentation fault. MAIN__ () at select_type_4.f90:166 166 if (cnt /= 4) call abort() but this statement is executed for the third time when the chash happens: Breakpoint 2, MAIN__ () at select_type_4.f90:166 166 if (cnt /= 4) call abort() 2: /x $r2 = 0x8db4 1: x/i $pc => 0x8b14 : ldr r3, [r2] (gdb) c Continuing. 1.23000002 Breakpoint 2, MAIN__ () at select_type_4.f90:166 166 if (cnt /= 4) call abort() 2: /x $r2 = 0x8dcc 1: x/i $pc => 0x8b14 : ldr r3, [r2] (gdb) c Continuing. 42 Breakpoint 2, MAIN__ () at select_type_4.f90:166 166 if (cnt /= 4) call abort() 2: /x $r2 = 0xf15aea17 1: x/i $pc => 0x8b14 : ldr r3, [r2] this looks like some loop optimization problem.