Lots of fortran failures on this target. The first is: Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortr an -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /home/dave/gnu/gcc/ gcc/gcc/testsuite/gfortran.dg/PR19872.f -O0 -pedantic-errors -B/home/dave/g nu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgfortran/.libs -L/home/dave/g nu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgfortran/.libs -L/home/dave/g nu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgfortran/.libs -L/home/dave/g nu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libiberty -lm -o ./PR19872.ex e (timeout = 300) PASS: gfortran.dg/PR19872.f -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-g nueabi/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnu eabi/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objd ir/armv5tejl-unknown-linux-gnueabi/./libgfortran/.libs:/home/dave/gnu/gcc/objdir /armv5tejl-unknown-linux-gnueabi/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/g cc:/home/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/libstdc++-v3/.libs: /home/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/libgomp/.libs:/home/da ve/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/opt/gnu/ gcc/gcc-4.3.3/lib:/home/dave/opt/gnu/lib FAIL: gfortran.dg/PR19872.f -O0 execution test Breakpoint 2, 0x401b4aa0 in abort () from /lib/libc.so.6 (gdb) bt #0 0x401b4aa0 in abort () from /lib/libc.so.6 #1 0x400a8614 in _gfortran_abort () at ../../../gcc/libgfortran/intrinsics/abort.c:34 #2 0x000088ac in MAIN__ () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/PR19872.f:14 Starting program: /home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/PR19872.xg Breakpoint 3, MAIN__ () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/PR19872.f:14 14 if(i(1).ne.9.or.i(2).ne.8.or.i(3).ne.7.or.i(4).ne.6)call abort (gdb) p i $6 = (214748364, 214748364, 214748364, 214748364) However, -bash-3.2$ cat fort.1 9 8 7 6
John, two questions: a) Does it help to set GFORTRAN_UNBUFFERED_ALL=1 before running the binary? b) I assume this is not a regression, is it?
It appears to be a regression. See results for 4.4: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02690.html I'll rebuild 4.5 and check point a.
(In reply to comment #2) > It appears to be a regression. See results for 4.4: > I'll rebuild 4.5 and check point a. Thanks - I marked it as regression, but without having access to armv5tejl it is impossible to debug - thus you need to do this deed. Can you also do the following: Using the 4.4 or 4.5 binary with the 4.5 or 4.4 libgfortran. I suspect that libgfortran has a bug. As some bugfixes went also into 4.4.x, it might be that the latest 4.4.x branch has the same bug. - At least finding the regression-causing bug should be easier if it is in libgfortran as one can rather quickly build it, without rebuilding the while of GCC.
Reverting back to... TREE_PUBLIC (ic_void_ptr_var) = 0; in the proposed patch results in the missing symbols again. Can we just leave... TREE_PUBLIC (ic_void_ptr_var) = 1; and find some way to coalesce the symbols so that the failure in... FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation, -fprofile-generate -D_PROFILE_GENERATE disappears. Lastly, any chance we can change this to a P1 so that it is fixed before the gcc 4.5 release?
(In reply to comment #4) > Reverting back to... > > TREE_PUBLIC (ic_void_ptr_var) = 0; > > in the proposed patch results in the missing symbols again. > Can we just leave... > > TREE_PUBLIC (ic_void_ptr_var) = 1; > > and find some way to coalesce the symbols so that the failure in... > > FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation, -fprofile-generate > -D_PROFILE_GENERATE > > disappears. Lastly, any chance we can change this to a P1 so that it is fixed > before the gcc 4.5 release? > Sorry. Wrong PR.
Subject: Re: [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > Can you also do the following: Using the 4.4 or 4.5 binary with the 4.5 or 4.4 > libgfortran. I suspect that libgfortran has a bug. As some bugfixes went also > into 4.4.x, it might be that the latest 4.4.x branch has the same bug. - At > least finding the regression-causing bug should be easier if it is in > libgfortran as one can rather quickly build it, without rebuilding the while of From my posted test results, I see revision 148947 was ok and 149580 was bad. See <http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg02644.html> and <http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00879.html>. Dave
GFORTRAN_UNBUFFERED_ALL=1 doesn't help. Test runs successfully with "installed" version of libgfortran: -bash-3.2$ ldd PR19872.xg libgfortran.so.3 => /home/dave/opt/gnu/gcc/gcc-4.3.3/lib/libgfortran.so.3 (0x40026000) ... So, problem is in libgfortran.
You will have to narrow this down with a regression hunt. Just eyeballing some things, maybe 148769 or 149398. Just a guess though. I do not see the failure but it is related to list reading and arrays I suppose.
GCC 4.5.0 is being released. Deferring to 4.5.1.
Subject: Re: [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > Can you also do the following: Using the 4.4 or 4.5 binary with the 4.5 or 4.4 > libgfortran. I suspect that libgfortran has a bug. As some bugfixes went also > into 4.4.x, it might be that the latest 4.4.x branch has the same bug. - At > least finding the regression-causing bug should be easier if it is in > libgfortran as one can rather quickly build it, without rebuilding the while of > GCC. I don't think the bug is in libgfortran, rather it appears libgfortran is being miscompiled. Thus, it's going to take some time to find the regression. Dave
I can pretty much see this on a v7 arm-linux-gnueabi target with 157994 (i.e. using a libgfortran from my 4.5 tree, causes this test to fail and using the system libgfortran things just work). On this target peeking at the values using gdb . I see that as soon as gfortran_transfer_array is completed the value in i is this random number. Don't know enough yet about libgfortran to figure out where the miscompile is happening. Digging. GNU gdb (GDB) 7.0.90.20100309-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/a.out...done. (gdb) b _gfortran_transfer_array Breakpoint 1 at 0x8508 (gdb) r Starting program: /tmp/a.out Breakpoint 1, *_gfortran_transfer_array (dtp=0xbef2ae60, desc=0xbef2afd8, kind=4, charlen=0) at /home/ramrad01/trunk/libgfortran/io/transfer.c:1863 1863 if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) != IOPARM_LIBRETURN_OK) (gdb) finish Run till exit from #0 *_gfortran_transfer_array (dtp=0xbef2ae60, desc=0xbef2afd8, kind=4, charlen=0) at /home/ramrad01/trunk/libgfortran/io/transfer.c:1863 0x00008878 in MAIN__ () at /home/ramrad01/trunk/gcc/testsuite/gfortran.dg/PR19872.f:13 13 read(1,*)i (gdb) p i $1 = (2147483647, 2147483647, 2147483647, 2147483647)
A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . 2009-07-02 Richard Guenther <rguenther@suse.de> * tree-ssa-live.c (remove_unused_locals): Do not remove heap variables. * tree-ssa-structalias.c (handle_lhs_call): Delay setting of DECL_EXTERNAL for HEAP variables. (compute_points_to_sets): Set DECL_EXTERNAL for escaped HEAP variables. Do not adjust RESTRICT vars. (find_what_var_points_to): Nobody cares if something points to READONLY. My tools were configured as /home/ramrad01/cross-build/src/gcc-trunk/configure --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --with-cpu=cortex-a8 --with-fpu=vfp3 --with-float=softfp In the middle of debugging further now to get to a reduced testcase given that the failure is a miscompile somewhere deep inside libgfortran.
(In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . > > 2009-07-02 Richard Guenther <rguenther@suse.de> > > * tree-ssa-live.c (remove_unused_locals): Do not remove > heap variables. > * tree-ssa-structalias.c (handle_lhs_call): Delay setting > of DECL_EXTERNAL for HEAP variables. > (compute_points_to_sets): Set DECL_EXTERNAL for escaped > HEAP variables. Do not adjust RESTRICT vars. > (find_what_var_points_to): Nobody cares if something > points to READONLY. > > My tools were configured as > > /home/ramrad01/cross-build/src/gcc-trunk/configure > --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran > --with-cpu=cortex-a8 --with-fpu=vfp3 --with-float=softfp > > > In the middle of debugging further now to get to a reduced testcase given that > the failure is a miscompile somewhere deep inside libgfortran. The change shouldn't cause excessive changes, so if you compare object files with and without that revision you should get at most a single file I would guess. If the change reproduces with a cross compiler (please provide configuration and compiler command-line details) I can have a look. Note that there were later fixes to that patch I believe (like the fix for PR40617). Unless you are sure you are running exactly into the same problem bisection may lead you to false intermediate broken libgfortran.
Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . I don't think this is it. r149263 is bad and r149105 is ok. http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00659.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00989.html Dave
(In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . Sigh, that should read 149170. > I don't think this is it. r149263 is bad and r149105 is ok. > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00659.html > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00989.html Will try and debug some more given what Richi said earlier.
Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > (In reply to comment #12) > > A git bisect between the ranges suggested by Dave in Comment #6, gave me > > r149470 this as the first broken commit using a cross-compiler to > > arm-linux-gnueabi with qemu as the simulator . > > Sigh, that should read 149170. Confirmed. See: http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01184.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01274.html Dave
Created attachment 20389 [details] Testcase for the problem. Can this bug be reprioritized ? Deep inside _gfortrani_set_integer, there's an incorrect sibling call to memcpy where it shouldn't be doing so. 64: e28d1010 add r1, sp, #16 68: e3a02004 mov r2, #4 6c: e521c008 str ip, [r1, #-8]! 70: e28dd014 add sp, sp, #20 74: e49de004 pop {lr} ; (ldr lr, [sp], #4) 78: eafffffe b 0 <memcpy> 78: R_ARM_PLT32 memcpy There's no reason why this should be being marked as a valid tail call here. From the tailcall dumps. set_integer (void * dest, GFC_INTEGER_8 value, int length) { GFC_INTEGER_1 tmp; GFC_INTEGER_2 tmp; GFC_INTEGER_4 tmp; GFC_INTEGER_8 tmp; GFC_INTEGER_1 tmp.30; GFC_INTEGER_2 tmp.29; GFC_INTEGER_4 tmp.28; size_t length.27; <bb 2>: switch (length_1(D)) <default: <L4>, case 1: <L3>, case 2: <L2>, case 4: <L1>, case 8: <L0>> <L0>: tmp = value_2(D); memcpy (dest_4(D), &tmp, 8); [tail call] goto <bb 8>; <L1>: tmp.28_5 = (GFC_INTEGER_4) value_2(D); tmp = tmp.28_5; memcpy (dest_4(D), &tmp, 4); [tail call] goto <bb 8>; <L2>: tmp.29_7 = (GFC_INTEGER_2) value_2(D); tmp = tmp.29_7; memcpy (dest_4(D), &tmp, 2); [tail call] goto <bb 8>; <L3>: tmp.30_9 = (GFC_INTEGER_1) value_2(D); tmp = tmp.30_9; memcpy (dest_4(D), &tmp, 1); [tail call] goto <bb 8>; <L4>: internal_error (0B, &"Bad integer kind"[0]); <bb 8>: return; } Attached is a testcase for this . Reproducible by building a cross-compiler to arm-eabi . ../trunk/configure --with-cpu=cortex-a8 --target=arm-none-eabi --enable-languages=c And command line options for the testcase are just -O2. You can reproduce this problem with r149170 and the fix up patch applied as well. cheers Ramana
Looking at more dumps this morning with the testcase and you can see that in the not working case all the "tmp" variables aren't marked as being call-clobbered. Alias information for set_integer Aliased symbols tmp, UID D.1276, GFC_INTEGER_8, is addressable tmp, UID D.1279, GFC_INTEGER_4, is addressable .MEM, UID D.2024, void, is global, call clobbered, default def: .MEM_11(D) tmp, UID D.1281, GFC_INTEGER_2, is addressable tmp, UID D.1283, GFC_INTEGER_1, is addressable whereas in the case that it was working - Alias information for set_integer Aliased symbols tmp, UID D.1276, GFC_INTEGER_8, is addressable, call clobbered tmp, UID D.1279, GFC_INTEGER_4, is addressable, call clobbered .MEM, UID D.2024, void, is global, call clobbered, default def: .MEM_11(D) tmp, UID D.1281, GFC_INTEGER_2, is addressable, call clobbered tmp, UID D.1283, GFC_INTEGER_1, is addressable, call clobbered
Mine.
Created attachment 20393 [details] patch
Created attachment 20394 [details] patch for 4.5 branch
Subject: Bug 43572 Author: rguenth Date: Fri Apr 16 13:21:38 2010 New Revision: 158418 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158418 Log: 2010-04-16 Richard Guenther <rguenther@suse.de> PR tree-optimization/43572 * tree-ssa-alias.h (call_may_clobber_ref_p): Declare. * tree-ssa-alias.c (call_may_clobber_ref_p): Export. * tree-flow.h (is_call_clobbered): Remove. * tree-flow-inline.h (is_call_clobbered): Likewise. * tree-dfa.c (dump_variable): Do not dump call clobber state. * tree-nrv.c (dest_safe_for_nrv_p): Use the alias oracle. (execute_return_slot_opt): Adjust. * tree-tailcall.c (suitable_for_tail_opt_p): Remove check for call clobbered vars here. (find_tail_calls): Move tailcall verification to the proper place. * gcc.dg/tree-ssa/tailcall-5.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/tailcall-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow-inline.h trunk/gcc/tree-flow.h trunk/gcc/tree-nrv.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-tailcall.c
Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply that there.
(In reply to comment #23) > Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply > that > there. > The patch works fine on the 4.5 branch with arm-linux-gnueabi. A bootstrap with --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp succeeds and the number of fortran testfailures drops down nicely from 721 to just 1. No regressions in libstdc++ or g++. There are some extra guality failures but there have been quite a few for a while on this board and I need to check with a newer gdb on that board to see what's going on. Hence I'd say this is good to go. cheers Ramana
Fixed.
Subject: Bug 43572 Author: rguenth Date: Mon Apr 19 09:12:13 2010 New Revision: 158507 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158507 Log: 2010-04-19 Richard Guenther <rguenther@suse.de> PR tree-optimization/43572 * tree-tailcall.c (find_tail_calls): Verify the tail call properly. * gcc.dg/tree-ssa/tailcall-5.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/tailcall-5.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-tailcall.c
(In reply to comment #22) > Subject: Bug 43572 > > Author: rguenth > Date: Fri Apr 16 13:21:38 2010 > New Revision: 158418 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158418 > Log: > 2010-04-16 Richard Guenther <rguenther@suse.de> > > PR tree-optimization/43572 I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it first when my 4.5-based gcc regressed on this test, and found evidence that trunk regressed similary between r158417 and r158459: http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01476.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01534.html I'm now starting a C-only bootstrap+regtest of 4.5 with this one reverted to verify.
(In reply to comment #27) > I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it first > when my 4.5-based gcc regressed on this test, and found evidence that trunk > regressed similary between r158417 and r158459: > > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01476.html > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01534.html > > I'm now starting a C-only bootstrap+regtest of 4.5 with this one reverted to > verify. Confirmed, reverting the PR43572 fix restores the expected tailcall in arm's sibcall-1.c test case. I don't know if the tailcall-blocking fix can be made to distinguish between references to local auto variables and references to formal parameters (which is what sibcall-1.c needs). If it can't, perhaps just XFAIL sibcall-1.c ?
Subject: Re: [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers On Tue, 20 Apr 2010, mikpe at it dot uu dot se wrote: > ------- Comment #27 from mikpe at it dot uu dot se 2010-04-20 23:34 ------- > (In reply to comment #22) > > Subject: Bug 43572 > > > > Author: rguenth > > Date: Fri Apr 16 13:21:38 2010 > > New Revision: 158418 > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158418 > > Log: > > 2010-04-16 Richard Guenther <rguenther@suse.de> > > > > PR tree-optimization/43572 > > I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it first > when my 4.5-based gcc regressed on this test, and found evidence that trunk > regressed similary between r158417 and r158459: > > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01476.html > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01534.html > > I'm now starting a C-only bootstrap+regtest of 4.5 with this one reverted to > verify. Try Index: gcc/tree-tailcall.c =================================================================== --- gcc/tree-tailcall.c (revision 158562) +++ gcc/tree-tailcall.c (working copy) @@ -469,6 +469,7 @@ find_tail_calls (basic_block bb, struct FOR_EACH_REFERENCED_VAR (var, rvi) { if (!is_global_var (var) + && TREE_CODE (var) != PARM_DECL && ref_maybe_used_by_stmt_p (call, var)) return; }
(In reply to comment #29) > Try > > Index: gcc/tree-tailcall.c > =================================================================== > --- gcc/tree-tailcall.c (revision 158562) > +++ gcc/tree-tailcall.c (working copy) > @@ -469,6 +469,7 @@ find_tail_calls (basic_block bb, struct > FOR_EACH_REFERENCED_VAR (var, rvi) > { > if (!is_global_var (var) > + && TREE_CODE (var) != PARM_DECL > && ref_maybe_used_by_stmt_p (call, var)) > return; > } > With PR43572 fix reinstated and this patch applied on top, sibcall-1.c doesn't fail any more and there are no other regressions (full bootstrap + regtest all languages except ada). Thanks for the quick fix.
Subject: Bug 43572 Author: rguenth Date: Fri Apr 23 15:46:23 2010 New Revision: 158671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158671 Log: 2010-04-23 Richard Guenther <rguenther@suse.de> PR tree-optimization/43572 * tree-tailcall.c (find_tail_calls): Allow PARM_DECL uses. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-tailcall.c
Subject: Bug 43572 Author: rguenth Date: Fri Apr 23 15:47:44 2010 New Revision: 158672 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158672 Log: 2010-04-23 Richard Guenther <rguenther@suse.de> PR tree-optimization/43572 * tree-tailcall.c (find_tail_calls): Allow PARM_DECL uses. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-tailcall.c
*** Bug 43904 has been marked as a duplicate of this bug. ***