[Bug tree-optimization/41089] New: [4.5 Regression] r147980 (New SRA) breaks stdargs

[Bug tree-optimization/41089] New: [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

r147980 [1] breaks stdargs on alpha [2]:

FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O1 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -Os 
...
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg "f15: va_list escapes 1,
needs to save all GPR units and all FPR units"

Before new SRA, stdarg dump for gcc.dg/tree-ssa/stdarg-2.c, f15 () showed:

--cut here--
va_list escapes in # .MEMD.2039_12 = VDEF <.MEMD.2039_2>
apD.2040 = apD.1263;

f15: va_list escapes 1, needs to save all GPR units and all FPR units.
--cut here--

With new SRA (r147980):

bb2 will be executed at most once for each va_start in bb2
bb3 will be executed at most once for each va_start in bb2
f15: va_list escapes 0, needs to save 8 GPR units and 0 FPR units.

The last OK testresults were from r147610 [3] and started to fail in r148747
[4]

The problem can be triggered by compiling following test (distilled from
stdarg-2.c) with a crosscompiler to alpha-linux-gnu:

--cut here--
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;

long x;

inline void __attribute__((always_inline))
f15_1 (va_list ap)
{
  x = __builtin_va_arg(ap,long);
}

void
f15 (int i, ...)
{
  va_list ap;
  __builtin_va_start(ap,i);
  f15_1 (ap);
  __builtin_va_end(ap);
}
--cut here--

gcc -O2 -fdump-tree-stdarg.

Runtime failure will be triggered by following test (sorry for the debug
printk's):

--cut here--
# 1 "t.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "t.c"
# 1 "/space/uros/gcc-build-44/gcc/include/stdarg.h" 1 3 4
# 40 "/space/uros/gcc-build-44/gcc/include/stdarg.h" 3 4
typedef __builtin_va_list __gnuc_va_list;
# 102 "/space/uros/gcc-build-44/gcc/include/stdarg.h" 3 4
typedef __gnuc_va_list va_list;
# 2 "t.c" 2

extern void abort (void);

int foo_arg;
long x;

void
foo (int v, va_list ap)
{
  printf ("__base = %p\n", ap.__base);
  printf ("__offset = %i\n", ap.__offset);
  switch (v)
    {
    case 5: foo_arg = __builtin_va_arg(ap,int);
    printf ("foo_arg = %i\n", foo_arg);
    break;
    default: abort ();
    }
  printf ("__base = %p\n", ap.__base);
  printf ("__offset = %i\n", ap.__offset);
}

void
__attribute__((noinline))
f4 (int i, ...)
{
  va_list ap;
  __builtin_va_start(ap,i);
  printf ("f4 __base = %p\n", ap.__base);
  printf ("f4 __offset = %i\n", ap.__offset);
  x = __builtin_va_arg(ap,double);


  foo (i, ap);

  printf ("f4 __base = %p\n", ap.__base);
  printf ("f4 __offset = %i\n", ap.__offset);
  __builtin_va_end(ap);
}

int
main (void)
{
f4 (5, 16.0, 128);
  if (x != 16 || foo_arg != 128)
    abort ();
return 0;
}
--cut here--

foo_arg will be 0 at the final test.

[1] http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html

[2] http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01508.html
[3] http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01614.html
[4] http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg01912.html


-- 
           Summary: [4.5 Regression] r147980 (New SRA) breaks stdargs
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ubizjak at gmail dot com
GCC target triplet: alphaev68-unknown-linux-gnu


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #1 from ubizjak at gmail dot com  2009-08-17 12:16 -------
Created an attachment (id=18383)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18383&action=view)
dump pack of small testcase for r147980


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #2 from ubizjak at gmail dot com  2009-08-17 12:18 -------
Created an attachment (id=18384)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18384&action=view)
dump pack of small testcase for r147979


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-25 21:53:10
               date|                            |


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #3 from jamborm at gcc dot gnu dot org  2009-08-31 09:03 -------
I'm back from vacation and aware of this problem.  I will look at it once I am
through all the mail and similar stuff (provided I don't find anything more
urgent) which will take a while.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #4 from jamborm at gcc dot gnu dot org  2009-09-04 18:45 -------
At the moment I believe that I have basically reintroduced  PR 30791
- except that the bug really does not provide the description of the
problem which is instead in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01176.html.

Since  alias-improvements have brought  aliasing information  to the
early stages,  I am now testing  whether we can  move pass_stdarg up
right before early SRA.  I'm running the test on an x86_64 now, will
try to do it on some other platform if the test finishes fine.

If it doesn't work for some reason, I will tend to fix this by a
hack very similar to the patch in the email linked above.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-08-25 21:53:10         |2009-09-04 18:45:26
               date|                            |


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2009-09-04 18:59 -------
Running the stdarg pass too early, before at least some DCE, means functions
that don't really need stdarg set up, might set it up unnecessarily.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #6 from jamborm at gcc dot gnu dot org  2009-09-04 19:01 -------
For a reference, this is the patch I am testing:

Index: gcc/passes.c
===================================================================
--- gcc/passes.c        (revision 151421)
+++ gcc/passes.c        (working copy)
@@ -562,6 +562,7 @@ init_optimization_passes (void)
             alias information also rewrites no longer addressed
             locals into SSA form if possible.  */
          NEXT_PASS (pass_build_ealias);
+         NEXT_PASS (pass_stdarg);
          NEXT_PASS (pass_sra_early);
          NEXT_PASS (pass_copy_prop);
          NEXT_PASS (pass_merge_phi);
@@ -620,7 +621,6 @@ init_optimization_passes (void)
       NEXT_PASS (pass_phiopt);
       NEXT_PASS (pass_tail_recursion);
       NEXT_PASS (pass_ch);
-      NEXT_PASS (pass_stdarg);
       NEXT_PASS (pass_lower_complex);
       NEXT_PASS (pass_sra);
       NEXT_PASS (pass_rename_ssa_copies);


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #7 from jamborm at gcc dot gnu dot org  2009-09-04 19:05 -------
(In reply to comment #5)
> Running the stdarg pass too early, before at least some DCE, means functions
> that don't really need stdarg set up, might set it up unnecessarily.
> 

The comment in http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01262.html
was the reason why Richi suggested that we try this anyway.
(Unfortunately, I have not looked into this thoroughly enough to judge
for myself... yet, hopefully, sort of).


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #8 from ubizjak at gmail dot com  2009-09-04 21:03 -------
(In reply to comment #6)
> For a reference, this is the patch I am testing:

Yes, this patch fixes stdarg failures from [1] with preliminary test:

FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O1 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -Os 
...
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg "f15: va_list escapes 1,
needs to save all GPR units and all FPR units"

[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00357.html

I will start full bootstrap and regression test over night.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #9 from ubizjak at gmail dot com  2009-09-05 06:08 -------
(In reply to comment #8)

> I will start full bootstrap and regression test over night.

The patch was bootstrapped and regression tested on alphaev68-linux-gnu where
it fixes mentioned failures.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #10 from jamborm at gcc dot gnu dot org  2009-09-08 17:10 -------
We have talked about this on IRC today and in the end I agreed that
pass_stdarg should be scheduled rather late.  This means that we
probably should return to the old behavior of ignoring va_lists in the
early SRA.

Thus I am now bootstrapping and testing the following patch on
x86_64-linux.  Uros, can you please test it on Alpha?  Thanks.


2009-09-08  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/41089
        * tree-sra.c (find_var_candidates): Do not consider va_lists in
        early SRA.

Index: mine/gcc/tree-sra.c
===================================================================
--- mine.orig/gcc/tree-sra.c
+++ mine/gcc/tree-sra.c
@@ -1165,7 +1165,13 @@ find_var_candidates (void)
          || !COMPLETE_TYPE_P (type)
          || !host_integerp (TYPE_SIZE (type), 1)
           || tree_low_cst (TYPE_SIZE (type), 1) == 0
-         || type_internals_preclude_sra_p (type))
+         || type_internals_preclude_sra_p (type)
+         /* Fix for PR 41089.  tree-stdarg.c needs to have va_lists intact but
+             we also want to schedule it rather late.  Thus we ignore it in
+             the early pass. */
+         || (sra_mode == SRA_MODE_EARLY_INTRA
+             && (TYPE_MAIN_VARIANT (TREE_TYPE (var))
+                 == TYPE_MAIN_VARIANT (va_list_type_node))))
        continue;

       bitmap_set_bit (candidate_bitmap, DECL_UID (var));


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #11 from ubizjak at gmail dot com  2009-09-09 14:44 -------
(In reply to comment #10)

> Thus I am now bootstrapping and testing the following patch on
> x86_64-linux.  Uros, can you please test it on Alpha?  Thanks.

This patch fixes gcc.c-torture/execute/stdarg-4.c and
gcc.dg/tree-ssa/stdarg-2.c, but both gcc.c-torture/execute/stdarg-1.c execute
failures remain.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #12 from jamborm at gcc dot gnu dot org  2009-09-09 16:05 -------
(In reply to comment #11)
> (In reply to comment #10)
> 
> > Thus I am now bootstrapping and testing the following patch on
> > x86_64-linux.  Uros, can you please test it on Alpha?  Thanks.
> 
> This patch fixes gcc.c-torture/execute/stdarg-4.c and
> gcc.dg/tree-ssa/stdarg-2.c, but both gcc.c-torture/execute/stdarg-1.c execute
> failures remain.
> 

My attempts at cross-compiling these testcases seem to indicate that
no early SRA happens in gcc.dg/tree-ssa/stdarg-2.c (although ap gets
scalarized by late SRA in f15 but that is too late to affect the dumps
in the stdarg tree pass) and no SRA whatsoever takes place in
gcc.c-torture/execute/stdarg-1.c.  Thus I believe SRA has nothing to
do with these remaining failures.  If you want to confirm this
independently, compile them with -fno-tree-sra.

This also makes me believe that the patch is the one to commit.  I
will send it to the mailing list shortly.  Thanks for testing.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #13 from ubizjak at gmail dot com  2009-09-09 16:23 -------
(In reply to comment #12)

> My attempts at cross-compiling these testcases seem to indicate that
> no early SRA happens in gcc.dg/tree-ssa/stdarg-2.c (although ap gets
> scalarized by late SRA in f15 but that is too late to affect the dumps
> in the stdarg tree pass) and no SRA whatsoever takes place in
> gcc.c-torture/execute/stdarg-1.c.  Thus I believe SRA has nothing to
> do with these remaining failures.  If you want to confirm this
> independently, compile them with -fno-tree-sra.

Thanks, I will analyse these remaining failures in more detail.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #14 from jamborm at gcc dot gnu dot org  2009-09-09 16:50 -------
Subject: Bug 41089

Author: jamborm
Date: Wed Sep  9 16:50:15 2009
New Revision: 151566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151566
Log:
2009-09-09  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/41089
        * tree-sra.c (find_var_candidates): Do not consider va_lists in
        early SRA.



Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-sra.c


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #15 from ubizjak at gmail dot com  2009-09-10 08:48 -------
This is the test that still fails:

--cut here--
extern void abort (void);

int foo_arg;
long x;

static void
foo (int v, __builtin_va_list ap)
{
  switch (v)
    {
    case 5: foo_arg = __builtin_va_arg(ap,int); break;
    default: abort ();
    }
}

void
f4 (int i, ...)
{
  __builtin_va_list ap;

  __builtin_va_start(ap,i);
  x = __builtin_va_arg(ap,double);
  foo (i, ap);
  __builtin_va_end(ap);
}

int
main (void)
{
f4 (5, 16.0, 128);
  if (x != 16 || foo_arg != 128)
    abort ();
return 0;
}
--cut here--

The failure is triggered when foo() is inlined into f4(), so with above test we
fail also at -O2.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #16 from ubizjak at gmail dot com  2009-09-10 08:50 -------
.optimized tree dump:

;; Function f4 (f4)

f4 (int i)
{
  long int D.2098;
  int * D.2097;
  long unsigned int D.2096;
  int * D.2095;
  int foo_arg.4;
  struct  ap;
  long int x.3;
  double D.2080;
  int D.2079;
  double * D.2078;
  long int D.2076;
  long unsigned int iftmp.2;
  double * D.2072;
  long int D.2071;
  int D.2070;
  void * D.2069;

<bb 2>:
  __builtin_va_start (&ap, 0);
  D.2069_2 = ap.__base;
  D.2070_3 = ap.__offset;
  D.2071_4 = (long int) D.2070_3;
  D.2072_5 = (double *) D.2069_2;
  if (D.2071_4 <= 47)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  D.2076_6 = D.2071_4 + -48;
  iftmp.2_7 = (long unsigned int) D.2076_6;
  goto <bb 5>;

<bb 4>:
  iftmp.2_8 = (long unsigned int) D.2071_4;

<bb 5>:
  # iftmp.2_1 = PHI <iftmp.2_7(3), iftmp.2_8(4)>
  D.2078_9 = D.2072_5 + iftmp.2_1;
  D.2071_10 = D.2071_4 + 8;
  D.2079_11 = (int) D.2071_10;
  ap.__offset = D.2079_11;
  D.2080_12 = *D.2078_9;
  x.3_13 = (long int) D.2080_12;
  x = x.3_13;
  switch (i_14(D)) <default: <L4>, case 5: <L3>>

<L3>:
  D.2098_23 = (long int) D.2079_11;
  D.2097_24 = (int *) D.2069_2;
  D.2096_25 = (long unsigned int) D.2098_23;
  D.2095_26 = D.2097_24 + D.2096_25;
  foo_arg.4_27 = *D.2095_26;
  foo_arg = foo_arg.4_27;
  return;

<L4>:
  abort ();

}



;; Function main (main)

main ()
{
  int foo_arg.1;
  long int x.0;

<bb 2>:
  f4 (5, 1.6e+1, 128);
  x.0_1 = x;
  if (x.0_1 != 16)
    goto <bb 4>;
  else
    goto <bb 3>;

<bb 3>:
  foo_arg.1_2 = foo_arg;
  if (foo_arg.1_2 != 128)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  abort ();

<bb 5>:
  return 0;

}


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #17 from ubizjak at gmail dot com  2009-09-10 10:04 -------
Hm, the difference between 4.4.1 and mainline is in the whole bunch of stores
that are not present anymore in _.expand dump of 4.5.0.

This is 4.4.1:
=============

(note 14 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 2 14 3 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 56 [0x38])) [0 S8 A8])
        (reg:DI 17 $17)) -1 (nil))

(insn 3 2 4 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 64 [0x40])) [0 S8 A8])
        (reg:DI 18 $18)) -1 (nil))

(insn 4 3 5 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 72 [0x48])) [0 S8 A8])
        (reg:DI 19 $19)) -1 (nil))

(insn 5 4 6 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 80 [0x50])) [0 S8 A8])
        (reg:DI 20 $20)) -1 (nil))

(insn 6 5 7 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 88 [0x58])) [0 S8 A8])
        (reg:DI 21 $21)) -1 (nil))

(insn 7 6 8 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 8 [0x8])) [0 S8 A8])
        (reg:DI 49 $f17)) -1 (nil))

(insn 8 7 9 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 16 [0x10])) [0 S8 A8])
        (reg:DI 50 $f18)) -1 (nil))

(insn 9 8 10 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 24 [0x18])) [0 S8 A8])
        (reg:DI 51 $f19)) -1 (nil))

(insn 10 9 11 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 32 [0x20])) [0 S8 A8])
        (reg:DI 52 $f20)) -1 (nil))

(insn 11 10 12 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 40 [0x28])) [0 S8 A8])
        (reg:DI 53 $f21)) -1 (nil))

And this is 4.5.0:
=================

(insn 2 6 3 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 56 [0x38])) [0 S8 A8])
        (reg:DI 17 $17)) -1 (nil))

(insn 3 2 4 2 t.c:18 (set (mem/c:DI (plus:DI (reg/f:DI 64
virtual-incoming-args)
                (const_int 8 [0x8])) [0 S8 A8])
        (reg:DI 49 $f17)) -1 (nil))

(insn 4 3 5 2 t.c:18 (set (reg/v:DI 89 [ i ])
        (reg:DI 16 $16 [ i ])) -1 (nil))


Yeah. Register $18 that holds the value of 128 is not there.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2009-09-10 10:14 -------
Check if the backend properly handles aliasing here.  Likely

static tree
alpha_gimplify_va_arg_1 (tree type, tree base, tree offset,
                         gimple_seq *pre_p)
{
...
  ptr_type = build_pointer_type (type);

should be

  ptr_type = build_pointer_type_for_mode (type, ptr_mode, true);


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jakub at gcc dot gnu dot org]

------- Comment #19 from jakub at gcc dot gnu dot org  2009-09-10 10:17 -------
Compare *.stdarg dump results between 4.4.1 and 4.5...
When foo is inlined, f4 needs at least one GPR and one FPR saved.
In the alpha case, GPR number is the number of bytes that need saving and FPR
number is a bitmask, as documented above alpha_stdarg_optimize_hook.
So it should be 8 GPR and 3 FPR.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #20 from ubizjak at gmail dot com  2009-09-10 17:29 -------
I have compared the dumps of two functions:

--function 1, WORKS--
extern void abort (void);

int foo_arg;
long x;

void
f4 (int i, ...)
{
  __builtin_va_list ap;

  __builtin_va_start(ap,i);
  x = __builtin_va_arg(ap,double);
  foo_arg = __builtin_va_arg(ap,int);
  __builtin_va_end(ap);
}

--stdarg dump of function 1--
;; Function f4 (f4)

f4: va_list escapes 0, needs to save 16 GPR units and 3 FPR units.
f4 (int i)
{
  struct  ap;
  int foo_arg.2;
  int D.2032;
  int * D.2031;
  long unsigned int D.2030;
  int * D.2029;
  long int D.2028;
  long int x.1;
  double D.2026;
  int D.2025;
  double * D.2024;
  long int D.2022;
  long unsigned int iftmp.0;
  double * D.2018;
  long int D.2017;
  int D.2016;
  void * D.2015;

<bb 2>:
  __builtin_va_start (&ap, 0);
  D.2015_2 = ap.__base;
  D.2016_3 = ap.__offset;
  D.2017_4 = (long int) D.2016_3;
  D.2018_5 = (double *) D.2015_2;
  if (D.2017_4 <= 47)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  D.2022_6 = D.2017_4 + -48;
  iftmp.0_7 = (long unsigned int) D.2022_6;
  goto <bb 5>;

<bb 4>:
  iftmp.0_8 = (long unsigned int) D.2017_4;

<bb 5>:
  # iftmp.0_1 = PHI <iftmp.0_7(3), iftmp.0_8(4)>
  D.2024_9 = D.2018_5 + iftmp.0_1;
  D.2017_10 = D.2017_4 + 8;
  D.2025_11 = (int) D.2017_10;
  ap.__offset = D.2025_11;
  D.2026_12 = *D.2024_9;
  x.1_13 = (long int) D.2026_12;
  x = x.1_13;
  D.2028_16 = (long int) D.2025_11;
  D.2029_17 = (int *) D.2015_2;
  D.2030_18 = (long unsigned int) D.2028_16;
  D.2031_19 = D.2029_17 + D.2030_18;
  D.2028_20 = D.2028_16 + 8;
  D.2032_21 = (int) D.2028_20;
  ap.__offset = D.2032_21;
  foo_arg.2_22 = *D.2031_19;
  foo_arg = foo_arg.2_22;
  __builtin_va_end (&ap);
  return;

}

--function 2, FAILS--
extern void abort (void);

int foo_arg;
long x;

static void
foo (int v, __builtin_va_list ap)
{
  switch (v)
    {
    case 5: foo_arg = __builtin_va_arg(ap,int); break;
    default: abort ();
    }
}

void
f4 (int i, ...)
{
  __builtin_va_list ap;

  __builtin_va_start(ap,i);
  x = __builtin_va_arg(ap,double);
  foo (i, ap);
  __builtin_va_end(ap);
}

--stdarg dump of function 2--
;; Function f4 (f4)

f4: va_list escapes 0, needs to save 8 GPR units and 3 FPR units.
f4 (int i)
{
  long int D.2051;
  int * D.2050;
  long unsigned int D.2049;
  int * D.2048;
  int foo_arg.2;
  struct  ap;
  long int x.1;
  double D.2033;
  int D.2032;
  double * D.2031;
  long int D.2029;
  long unsigned int iftmp.0;
  double * D.2025;
  long int D.2024;
  int D.2023;
  void * D.2022;

<bb 2>:
  __builtin_va_start (&ap, 0);
  D.2022_2 = ap.__base;
  D.2023_3 = ap.__offset;
  D.2024_4 = (long int) D.2023_3;
  D.2025_5 = (double *) D.2022_2;
  if (D.2024_4 <= 47)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  D.2029_6 = D.2024_4 + -48;
  iftmp.0_7 = (long unsigned int) D.2029_6;
  goto <bb 5>;

<bb 4>:
  iftmp.0_8 = (long unsigned int) D.2024_4;

<bb 5>:
  # iftmp.0_1 = PHI <iftmp.0_7(3), iftmp.0_8(4)>
  D.2031_9 = D.2025_5 + iftmp.0_1;
  D.2024_10 = D.2024_4 + 8;
  D.2032_11 = (int) D.2024_10;
  ap.__offset = D.2032_11;
  D.2033_12 = *D.2031_9;
  x.1_13 = (long int) D.2033_12;
  x = x.1_13;
  switch (i_14(D)) <default: <L4>, case 5: <L3>>

<L3>:
  D.2051_23 = (long int) D.2032_11;
  D.2050_24 = (int *) D.2022_2;
  D.2049_25 = (long unsigned int) D.2051_23;
  D.2048_26 = D.2050_24 + D.2049_25;
  foo_arg.2_27 = *D.2048_26;
  foo_arg = foo_arg.2_27;
  __builtin_va_end (&ap);
  return;

<L4>:
  abort ();

}


Tracing through the tree-stdarg.c, the difference is in the number of calls to
va_list_counter_struct_op from this place:

                {
                  if (get_gimple_rhs_class (gimple_assign_rhs_code (stmt))
                      == GIMPLE_SINGLE_RHS)
                    {
                      /* Check for ap[0].field = temp.  */
>>>		      if (va_list_counter_struct_op (&si, lhs, rhs, true))
                        continue;

                      /* Check for temp = ap[0].field.  */
                      else if (va_list_counter_struct_op (&si, rhs, lhs,
                                                          false))
                        continue;
                    }

So indeed, in the failing case, there is only one assignment to  ap._offset and
in the working case, there are two assignments, resulting in correct number of
GPR bytes (== 2 registers) saved.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #21 from ubizjak at gmail dot com  2009-09-10 18:37 -------
Either -fno-tree-fre or -fno-tree-dce "fixes" this test in the sense that
somehow disables stdarg optimization:

f4: va_list escapes 1, needs to save all GPR units and all FPR units.

This all happens on top of:

Index: gcc/config/alpha/alpha.c
===================================================================
--- gcc/config/alpha/alpha.c    (revision 151587)
+++ gcc/config/alpha/alpha.c    (working copy)
@@ -6339,7 +6339,7 @@ alpha_gimplify_va_arg_1 (tree type, tree
     }

   addend = offset;
-  ptr_type = build_pointer_type (type);
+  ptr_type = build_pointer_type_for_mode (type, ptr_mode, true);

   if (TREE_CODE (type) == COMPLEX_TYPE)
     {
@@ -6420,7 +6420,7 @@ alpha_gimplify_va_arg (tree valist, tree

   indirect = pass_by_reference (NULL, TYPE_MODE (type), type, false);
   if (indirect)
-    type = build_pointer_type (type);
+    type = build_pointer_type_for_mode (type, ptr_mode, true);

   /* Find the value.  Note that this will be a stable indirection, or
      a composite of stable indirections in the case of complex.  */


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #22 from ubizjak at gmail dot com  2009-09-10 18:38 -------
richi?


-- 

ubizjak at gmail dot com changed:

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


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2009-09-10 21:41 -------
>From this:

  foo (i, ap);
  __builtin_va_end(ap);
}

--stdarg dump of function 2--
;; Function f4 (f4)

f4: va_list escapes 0, needs to save 8 GPR units and 3 FPR units.
f4 (int i)

I see va_list should obviously escape.  It does to foo.  So it's stdargs
fault.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rth at gcc dot gnu dot org]

------- Comment #24 from rth at gcc dot gnu dot org  2009-09-10 21:59 -------
No, foo has been inlined.  Escaping is not the problem.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2009-09-10 22:12 -------
The first store to ap.offset is dead.

<bb 5>:
  # iftmp.0_1 = PHI <iftmp.0_7(3), iftmp.0_8(4)>
  D.2024_9 = D.2018_5 + iftmp.0_1;
  D.2017_10 = D.2017_4 + 8;
  D.2025_11 = (int) D.2017_10;
  ap.__offset = D.2025_11;
  D.2026_12 = *D.2024_9;
  x.1_13 = (long int) D.2026_12;
  x = x.1_13;
  D.2028_16 = (long int) D.2025_11;
  D.2029_17 = (int *) D.2015_2;
  D.2030_18 = (long unsigned int) D.2028_16;
  D.2031_19 = D.2029_17 + D.2030_18;
  D.2028_20 = D.2028_16 + 8;
  D.2032_21 = (int) D.2028_20;
  ap.__offset = D.2032_21;

So if tree-stdarg relies on it it's bogus.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P4


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #26 from ubizjak at gmail dot com  2009-09-18 15:45 -------
Sigh... I hoped that blaming target-independent parts of the compiler will
somehow bring this bug above the radar (aka P3) for 4.5.0 release ;)


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #27 from ubizjak at gmail dot com  2009-09-27 16:12 -------
Blocker, blocks bootstrap on alpha, see PR41395.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2009-09-27 18:51 -------
Uros, did you fix the alpha backend vaarg gimplification yet?


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[ubizjak at gmail dot com]

------- Comment #29 from ubizjak at gmail dot com  2009-09-27 21:09 -------
(In reply to comment #28)
> Uros, did you fix the alpha backend vaarg gimplification yet?

Hm, I'm not aware of anything broken with gimplification (judging by the fact
that it worked until recent changes)... The only patch I have is the one from
Comment 21, and doesn't make any difference with the problem, reported in this
PR.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[rguenther at suse dot de]

------- Comment #30 from rguenther at suse dot de  2009-09-28 08:41 -------
Subject: Re:  [4.5 Regression] r147980 (New SRA)
 breaks stdargs

On Sun, 27 Sep 2009, ubizjak at gmail dot com wrote:

> ------- Comment #29 from ubizjak at gmail dot com  2009-09-27 21:09 -------
> (In reply to comment #28)
> > Uros, did you fix the alpha backend vaarg gimplification yet?
> 
> Hm, I'm not aware of anything broken with gimplification (judging by the fact
> that it worked until recent changes)... The only patch I have is the one from
> Comment 21, and doesn't make any difference with the problem, reported in this
> PR.

It doesn't make a difference for that it is needed either ;)

Richard.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

------- Comment #31 from jamborm at gcc dot gnu dot org  2009-09-29 13:49 -------
(In reply to comment #12)
> Thus I believe SRA has nothing to
> do with these remaining failures.  If you want to confirm this
> independently, compile them with -fno-tree-sra.
> 

...and so I un-assign this bug from myself.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jamborm at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #32 from ubizjak at gmail dot com  2010-01-21 20:25 -------
I would like RMs to reconsider the priority of this bug, since it shows
weakness in the generic part of the compiler. Please see comments #20, #25 (and
#26) for the analysis.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P4                          |P3
            Summary|[4.5 Regression] r147980    |[4.5 Regression] stdarg pass
                   |(New SRA) breaks stdargs    |produces wrong code


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #33 from rguenth at gcc dot gnu dot org  2010-01-22 11:25 -------
Well, w/o a way to reproduce the problem (read: execute code) I think you
have to do a better job analyzing the problem.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #34 from ubizjak at gmail dot com  2010-01-22 12:33 -------
(In reply to comment #33)
> Well, w/o a way to reproduce the problem (read: execute code) I think you
> have to do a better job analyzing the problem.

This is:

FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g 

from [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01777.html


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #35 from rguenth at gcc dot gnu dot org  2010-01-22 14:17 -------
(In reply to comment #34)
> (In reply to comment #33)
> > Well, w/o a way to reproduce the problem (read: execute code) I think you
> > have to do a better job analyzing the problem.
> 
> This is:
> 
> FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer 
> FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g 
> 
> from [1].
> 
> [1] http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01777.html

That doesn't make me have an alpha machine or a proper reduced testcase.
Note that it now only fails at -O3.

Please paste a reduced testcase that still fails and track down what
is the pass that does which wrong transformation.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #36 from ubizjak at gmail dot com  2010-01-22 17:26 -------
(In reply to comment #35)

> That doesn't make me have an alpha machine or a proper reduced testcase.
> Note that it now only fails at -O3.
> 
> Please paste a reduced testcase that still fails and track down what
> is the pass that does which wrong transformation.

Probably you should read Comment #20 all the way to the end... There are listed
_two_ testcases (with dumps) and the exact location in execute_optimize_stdarg
() of tree-stdarg.c where the problem happens.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[jakub at gcc dot gnu dot org]

------- Comment #37 from jakub at gcc dot gnu dot org  2010-01-22 19:05 -------
Well, as alpha is the only affected platform, it is a target problem.
The thing is, alpha unfortunately doesn't define va_list the same as x86_64 or
s390 or rs6000 - a single member array of structs.  So, in a function that
takes
va_list argument on x86_64/s390/rs6000 the parent fn va_list object is updated
(thus all writes to it are kept) but on alpha it is not and thus DSE can remove
those stores as dead.  In 4.4 and earlier tree-stdarg would bail out when it
saw an apX = apY assignment (struct copy), but apparently in 4.5 this is DCEd
away.  You can certainly just stop using the tree-stdarg computed info in alpha
backend (alpha is the only backend that uses the info and doesn't have va_list
either a void/char pointer, or single member array of structs; I'm afraid that
would be a code quality regression though, especially on alpha which badly
needs this), or we need to find out if there is anything tree-stdarg could do,
or we could tell DCE not to DCE away va_list RECORD_TYPE assignments before
tree-stdarg pass.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[jakub at gcc dot gnu dot org]

------- Comment #38 from jakub at gcc dot gnu dot org  2010-01-22 19:17 -------
In 4.4 the apY = apX; assignment isn't optimized out, because the code after it
reads from the apY's fields (apY is the struct from the inline, apX in the
caller).  But in 4.5 FRE replaces them by whatever is written into apX fields.
It surprises me FRE does this, I'd expect that the struct needs to be SRAed
first before such optimizations can do anything with it.

That said, other options would be prevent FRE from doing that kind of things
with RECORD_TYPE __builtin_va_list objects in the first fre pass, or for DCE1
to
somehow signalize to the stdarg pass if it removes an va_list = va_list
assignment that it should just signalize that va_list escapes.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenther at suse dot de]

------- Comment #39 from rguenther at suse dot de  2010-01-22 21:47 -------
Subject: Re:  [4.5 Regression] stdarg pass
 produces wrong code

On Fri, 22 Jan 2010, jakub at gcc dot gnu dot org wrote:

> ------- Comment #38 from jakub at gcc dot gnu dot org  2010-01-22 19:17 -------
> In 4.4 the apY = apX; assignment isn't optimized out, because the code after it
> reads from the apY's fields (apY is the struct from the inline, apX in the
> caller).  But in 4.5 FRE replaces them by whatever is written into apX fields.
> It surprises me FRE does this, I'd expect that the struct needs to be SRAed
> first before such optimizations can do anything with it.

It's a feature ;)  FRE can look through struct copies now and thus
can value-number x to 1 in s.a = 1; r = s; x = r.a;

> That said, other options would be prevent FRE from doing that kind of things
> with RECORD_TYPE __builtin_va_list objects in the first fre pass, or for DCE1
> to
> somehow signalize to the stdarg pass if it removes an va_list = va_list
> assignment that it should just signalize that va_list escapes.

or alpha could make the va_list struct copies volatile.  Or we can 
schedule tree-stdarg earlier.

Richard.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[steven at gcc dot gnu dot org]

------- Comment #40 from steven at gcc dot gnu dot org  2010-01-22 22:49 -------
Running tree-stdarg earlier would introduce non-obvious pass ordering
requirements IIUC.  I don't think that's a good idea...


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #41 from rguenth at gcc dot gnu dot org  2010-01-22 22:57 -------
(In reply to comment #40)
> Running tree-stdarg earlier would introduce non-obvious pass ordering
> requirements IIUC.  I don't think that's a good idea...

Well given that practically we moved stdarg towards the back by adding
early optimizations it would be not unreasonable to move it right after
pass_return_slot.  That retains scalar cleanup after final inlining.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[jakub at gcc dot gnu dot org]

------- Comment #42 from jakub at gcc dot gnu dot org  2010-01-23 08:13 -------
Well, stdarg wants to be scheduled after some kind of DCE, to avoid making
decisions from dead code.  So in that case we'd have to schedule a DCE pass
after retslot (perhaps just for cfun->stdarg functions), then stdarg, then
phiprop/fre.


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #43 from rguenth at gcc dot gnu dot org  2010-01-23 12:06 -------
Well, we run DCE during early optimizations and the CCP that runs before
pass_return_slot and after final inlining removes dead basic-blocks and
trivially dead insns already.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2009-09-04 18:45:26         |2010-01-23 12:06:11
               date|                            |


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[mmitchel at gcc dot gnu dot org]

------- Comment #44 from mmitchel at gcc dot gnu dot org  2010-02-17 17:20 -------
As I understand it, this is an Alpha-specific problem.  It may have an
Alpha-independent solution, but only users on Alpha will be affected.  So, I've
downgraded this to P5.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


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

[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #45 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=41089

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #46 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #47 from ubizjak at gmail dot com  2010-08-01 12:50 -------
(In reply to comment #39)

> or alpha could make the va_list struct copies volatile.  Or we can 
> schedule tree-stdarg earlier.

Well, following patch fixes remaining gcc.c-torture/execute/stdarg-1.c failure
as well:

Index: alpha/alpha.c
===================================================================
--- alpha/alpha.c       (revision 162794)
+++ alpha/alpha.c       (working copy)
@@ -5948,6 +5948,7 @@ alpha_build_builtin_va_list (void)
   ofs = build_decl (BUILTINS_LOCATION,
                    FIELD_DECL, get_identifier ("__offset"),
                    integer_type_node);
+  TREE_THIS_VOLATILE (ofs) = 1;
   DECL_FIELD_CONTEXT (ofs) = record;
   DECL_CHAIN (ofs) = space;


Does this patch makes sense w.r.t to stdarg optimizations?


-- 


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #48 from ubizjak at gmail dot com  2010-08-02 17:12 -------
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00021.html.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2010-
                   |                            |08/msg00021.html


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #49 from ubizjak at gmail dot com  2010-08-02 17:33 -------
Author: uros
Date: Mon Aug  2 17:26:40 2010
New Revision: 162826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162826
Log:
        target/41089
        * config/alpha/alpha.c (alpha_build_builtin_va_list): Mark __offset
        as volatile.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/alpha/alpha.c


-- 


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[uros at gcc dot gnu dot org]

------- Comment #50 from uros at gcc dot gnu dot org  2010-08-03 18:45 -------
Subject: Bug 41089

Author: uros
Date: Tue Aug  3 18:44:56 2010
New Revision: 162846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162846
Log:
        PR target/41089
        * config/alpha/alpha.c (alpha_build_builtin_va_list): Mark __offset
        as volatile.


Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/alpha/alpha.c


-- 


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

------- Comment #51 from ubizjak at gmail dot com  2010-08-03 18:53 -------
Fixed, but there are certainly better ways to fix, see [1] and [2].

[1] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00070.html
[2] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00165.html

So, marked as suspended...


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal


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

[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.2                       |4.5.3

--- Comment #52 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-16 13:03:31 UTC ---
GCC 4.5.2 is being released, adjusting target milestone.