[Bug libfortran/43572] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[Bug libfortran/43572] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[danglin at gcc dot gnu dot org]

------- Comment #2 from danglin at gcc dot gnu dot org  2010-03-31 18:08 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-04-01 09:41 -------
(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.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|FAIL: gfortran.dg/PR19872.f |[4.5 Regression] FAIL:
                   |execution test; formatted   |gfortran.dg/PR19872.f
                   |read - wrong numbers        |execution test; formatted
                   |                            |read - wrong numbers
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[howarth at nitro dot med dot uc dot edu]

------- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-04-01 11:26 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[howarth at nitro dot med dot uc dot edu]

------- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-04-01 11:25 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-04-01 20:51 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[danglin at gcc dot gnu dot org]

------- Comment #7 from danglin at gcc dot gnu dot org  2010-04-01 21:03 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-04-02 02:57 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-04-06 11:20 -------
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2010-04-09 20:06 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #11 from ramana at gcc dot gnu dot org  2010-04-10 08:45 -------
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)


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P4                          |P3
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-10 08:45:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #12 from ramana at gcc dot gnu dot org  2010-04-12 15:50 -------
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.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-04-12 15:59 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2010-04-12 16:02 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #15 from ramana at gcc dot gnu dot org  2010-04-12 17:21 -------
(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. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2010-04-15 13:44 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #17 from ramana at gcc dot gnu dot org  2010-04-15 18:39 -------
Created an attachment (id=20389)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20389&action=view)
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #18 from ramana at gcc dot gnu dot org  2010-04-16 07:46 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2010-04-16 08:59 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-04-10 08:45:21         |2010-04-16 08:59:28
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2010-04-16 10:00 -------
Created an attachment (id=20393)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20393&action=view)
patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-04-16 10:54 -------
Created an attachment (id=20394)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394&action=view)
patch for 4.5 branch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-04-16 13: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
        * 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2010-04-16 15:00 -------
Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply
that
there.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.0
            Summary|[4.5/4.6 Regression] FAIL:  |[4.5 Regression] FAIL:
                   |gfortran.dg/PR19872.f       |gfortran.dg/PR19872.f
                   |execution test; formatted   |execution test; formatted
                   |read - wrong numbers        |read - wrong numbers


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[ramana at gcc dot gnu dot org]

------- Comment #24 from ramana at gcc dot gnu dot org  2010-04-19 09:06 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2010-04-19 09:12 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|4.6.0                       |4.5.1 4.6.0
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2010-04-19 09:13 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[mikpe at it dot uu dot se]

------- 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.


-- 

mikpe at it dot uu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[mikpe at it dot uu dot se]

------- Comment #28 from mikpe at it dot uu dot se  2010-04-21 07:52 -------
(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 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenther at suse dot de]

------- Comment #29 from rguenther at suse dot de  2010-04-21 08:48 -------
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;
     }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[mikpe at it dot uu dot se]

------- Comment #30 from mikpe at it dot uu dot se  2010-04-23 01:24 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #31 from rguenth at gcc dot gnu dot org  2010-04-23 15:46 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[rguenth at gcc dot gnu dot org]

------- Comment #32 from rguenth at gcc dot gnu dot org  2010-04-23 15:48 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572

[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[pinskia at gcc dot gnu dot org]

------- Comment #33 from pinskia at gcc dot gnu dot org  2010-04-26 23:47 -------
*** Bug 43904 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tavianator at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572