User account creation filtered due to spam.

Bug 43572 - [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
Summary: [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read -...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.5.1
Assignee: Richard Biener
URL:
Keywords: wrong-code
: 43904 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-29 14:56 UTC by John David Anglin
Modified: 2010-04-27 06:13 UTC (History)
6 users (show)

See Also:
Host: armv5tejl-unknown-linux-gnueabi
Target: armv5tejl-unknown-linux-gnueabi
Build: armv5tejl-unknown-linux-gnueabi
Known to work: 4.5.1 4.6.0
Known to fail: 4.5.0
Last reconfirmed: 2010-04-16 08:59:28


Attachments
Testcase for the problem. (332 bytes, text/plain)
2010-04-15 18:39 UTC, Ramana Radhakrishnan
Details
patch (928 bytes, patch)
2010-04-16 10:00 UTC, Richard Biener
Details | Diff
patch for 4.5 branch (782 bytes, patch)
2010-04-16 10:54 UTC, Richard Biener
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2010-03-29 14:56:35 UTC
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
Comment 1 Tobias Burnus 2010-03-29 15:14:52 UTC
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?
Comment 2 John David Anglin 2010-03-31 18:08:47 UTC
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.
Comment 3 Tobias Burnus 2010-04-01 09:41:03 UTC
(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.
Comment 4 Jack Howarth 2010-04-01 11:25:24 UTC
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?
Comment 5 Jack Howarth 2010-04-01 11:26:13 UTC
(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.
Comment 6 dave 2010-04-01 20:51:20 UTC
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
Comment 7 John David Anglin 2010-04-01 21:03:08 UTC
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.
Comment 8 Jerry DeLisle 2010-04-02 02:57:32 UTC
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.
Comment 9 Richard Biener 2010-04-06 11:20:57 UTC
GCC 4.5.0 is being released.  Deferring to 4.5.1.
Comment 10 dave 2010-04-09 20:06:20 UTC
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
Comment 11 Ramana Radhakrishnan 2010-04-10 08:45:20 UTC
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)
Comment 12 Ramana Radhakrishnan 2010-04-12 15:50:07 UTC
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.

Comment 13 Richard Biener 2010-04-12 15:59:11 UTC
(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.
Comment 14 dave 2010-04-12 16:02:54 UTC
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
Comment 15 Ramana Radhakrishnan 2010-04-12 17:21:58 UTC
(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. 

Comment 16 dave 2010-04-15 13:44:39 UTC
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
Comment 17 Ramana Radhakrishnan 2010-04-15 18:39:30 UTC
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
Comment 18 Ramana Radhakrishnan 2010-04-16 07:46:46 UTC
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

Comment 19 Richard Biener 2010-04-16 08:59:27 UTC
Mine.
Comment 20 Richard Biener 2010-04-16 10:00:36 UTC
Created attachment 20393 [details]
patch
Comment 21 Richard Biener 2010-04-16 10:54:35 UTC
Created attachment 20394 [details]
patch for 4.5 branch
Comment 22 Richard Biener 2010-04-16 13:22:03 UTC
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

Comment 23 Richard Biener 2010-04-16 15:00:20 UTC
Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply that
there.
Comment 24 Ramana Radhakrishnan 2010-04-19 09:06:13 UTC
(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

Comment 25 Richard Biener 2010-04-19 09:12:33 UTC
Fixed.
Comment 26 Richard Biener 2010-04-19 09:13:06 UTC
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

Comment 27 Mikael Pettersson 2010-04-20 23:34:13 UTC
(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.
Comment 28 Mikael Pettersson 2010-04-21 07:52:23 UTC
(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 ?
Comment 29 rguenther@suse.de 2010-04-21 08:48:31 UTC
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;
     }

Comment 30 Mikael Pettersson 2010-04-23 01:24:13 UTC
(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.
Comment 31 Richard Biener 2010-04-23 15:46:46 UTC
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

Comment 32 Richard Biener 2010-04-23 15:48:01 UTC
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

Comment 33 Andrew Pinski 2010-04-26 23:47:12 UTC
*** Bug 43904 has been marked as a duplicate of this bug. ***