[Bug c++/40389] New: optimizer bug (possibly)

[Bug c++/40389] New: optimizer bug (possibly)

[keesjan at cobalt dot et dot tudelft dot nl]

After compiling a particular C++ program (see attachment) both with and without
the -O option, the program produces different results.

When compiled with -O, the program produces the output "(nil)", whereas when
compiled without any options, the program prints a non-null pointer (which may
of course vary between runs).

The program is only 121 lines long, and was obtained by reducing an initial set
of over 30.000 lines of code until no further reduction seemed to be possible
without suppressing the problem. For example, by moving the static variable "
fs_active_handle" into the main function, the problem "magically" disappears.
Also, when adding printf-statements to the functions, or by manually inlining
certain constructs, the problem disappears.

Due to the immense reduction of the code, the semantics of the code may not
seem clear anymore (that is, I am myself not sure what this program is supposed
to do anymore), but the problem with the optimizer clearly shows.

I have tried to use the tool valgrind to see if something illegal is happening
wrt copy-constructors/assignment operators (despite close inspection), but this
does not seem to be the case.


-- 
           Summary: optimizer bug (possibly)
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: keesjan at cobalt dot et dot tudelft dot nl
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/40389] optimizer bug (possibly)

[keesjan at cobalt dot et dot tudelft dot nl]

------- Comment #1 from keesjan at cobalt dot et dot tudelft dot nl  2009-06-09 15:49 -------
Created an attachment (id=17971)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17971&action=view)
The source code and compiler output, and a small script which reproduces the
bug.

Please see the script "reproduce.sh", which reproduces the bug and writes a log
to "info.txt". The particular output on my system can be found in that same log
file. The last few lines of this log file clearly indicate a difference between
the optimized and non-optimized code.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2009-06-09 17:11 -------
Confirmed.  Shorter testcase:
template <typename V> struct S
{
  V *f, *l;
  __attribute__ ((noinline)) S (void) { f = 0, l = 0; }
  void foo (V *x)
  {
    if (x->p != 0)
      x->p->n = x->n;
    else
      f = x->n;
    if (x->n != 0)
      x->n->p = x->p;
    else
      l = x->p;
  }
  __attribute__ ((noinline)) void bar (V *x)
  {
    x->n = 0;
    x->p = l;
    if (l != 0)
      l->n = x;
    else
      f = x;
    l = x;
  }
};

struct H;

struct A
{
  S <H> k;
};

struct H
{
  A *a;
  H *p, *n;
  __attribute__ ((noinline)) H (void) { p = 0, n = 0, a = 0; }
  __attribute__ ((noinline)) H (A *b) : a (b)
  {
    p = 0;
    n = 0;
    if (a != 0)
      a->k.bar (this);
  }
  __attribute__ ((noinline)) H (const H &h) : a (h.a)
  {
    p = 0;
    n = 0;
    if (a != 0)
      a->k.bar (this);
  }
  ~H (void) { if (a != 0) a->k.foo (this); }
  H &operator= (const H &o)
  {
    if (a != 0 || &o == this)
      __builtin_abort ();
    a = o.a;
    if (a != 0)
      a->k.bar (this);
    return *this;
  }
};

__attribute__ ((noinline))
H baz (void)
{
  return H (new A);
}

H g;

int
main (void)
{
  g = baz ();
  if (g.a->k.f != &g)
    __builtin_abort ();
  return 0;
}

doesn't fail with -O -fno-tree-sra, fails with -O.  I've added a few noinline
attributes to make the debugging easier.  Seems values from baz returned object
are cached in local variables across the bar call which modifies them.  Likely
gcc doesn't consider this object as having address taken, even when it is
returned by invisible reference.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-09 17:11:13
               date|                            |


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-09 20:25 -------
Hm, I don't see how it should make the decl addressable.  But I also don't
see what is wrong with what esra performs on trunk ...

I guess you refer to

@@ -1193,45 +374,45 @@
   S<H>::bar (D.2441_15, &g);

 <bb 6>:
-  D.2453_16 = D.2275.a;
+  D.2453_16 = SR.101_9;
   if (D.2453_16 != 0B)

?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
      Known to fail|4.4.0                       |4.4.0 4.5.0


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2009-06-09 21:21 -------
IMHO either we need to handle gimple_call_return_slot_opt_p cals in the
middle-end as taking address of the call's lhs, or the frontend needs to expand
it not as
D.2275 = baz (); [return slot optimization]
but as
baz (&D.2275);
Doing the latter can be problematic on targets which have special calling
conventions for the returns by invisible reference.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-06-09 21:27 -------
I don't see why this is an issue at all - in fact the address does not
escape(?)
but instead the assignment is inside the callee.  So

<bb 2>:
  D.2275 = baz (); [return slot optimization]
  SR.101_9 = D.2275.a;
  SR.102_11 = D.2275.p;
  SR.103_3 = D.2275.n;

as it looks like on trunk is still correct, no?  Which means, I still don't
see where it goes wrong ...


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2009-06-09 21:31 -------
I think this code is undefined as there is an address of a local variable being
taken and stored (explicitly when doing:
  __attribute__ ((noinline)) H (A *b) : a (b)
  {
    p = 0;
    n = 0;
    if (a != 0)
      a->k.bar (this);
  }

this is an address of a local variable (the temp in baz).


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2009-06-09 21:44 -------
CCing Jason on the validity of the testcase.
I don't see anything wrong with remembering this pointer for the duration of
the object, assuming the pointer is gone from the list in the destructor
(that's what the testcase does).
And, assuming the testcase is valid, the pointer to the temporary really
escapes.


-- 

jakub at gcc dot gnu dot org changed:

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


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

------- Comment #8 from jason at gcc dot gnu dot org  2009-06-10 19:37 -------
As Jakub says, it's not a problem to take the address of a local variable as
long as that address is only used during the variable's lifetime; the
destructor for the temporary removes all references to its address, so there's
nothing undefined.

The problem here seems to be that the address of the object escapes during its
own construction.  I guess we need a type flag to indicate this situation so we
can mark variables of such a type addressable when we create them.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-06-09 17:11:13         |2009-06-10 19:37:07
               date|                            |


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

------- Comment #9 from jason at gcc dot gnu dot org  2009-06-10 19:40 -------
Actually, I'm not sure I'm the right person to work on this bug, as we might
want this analysis to happen more in the optimizer.  That is, we see that
"this" escapes in one of the H constructors, so all H must be treated as
addressable.


-- 

jason at gcc dot gnu dot org changed:

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


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-06-10 19:47 -------
Can we have a less convoluted C-only testcase?  I still don't see what is
going on ...


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

------- Comment #11 from jason at gcc dot gnu dot org  2009-06-10 20:12 -------
I don't think it's possible to reproduce this in C because C doesn't have
constructors, so it's obvious when the address is taken.  Here's what's
happening:

baz uses new to allocate an A with f=0,l=0, call it A'
baz creates and returns a temporary H' with a=A',p=0,n=0
 bar modifies A', setting f and l to &H'.
(elided copy)
main calls operator= to copy H' to g.
 this sets a=A',p=0,n=0
  then bar sets g.p to &H', H'.n to &g and A'.l to &g.
main destroys H'.
 H'.p is 0, so we set A'.f to H'.n, or &g.
 H'.n is &g, so we set g.p to H'.p, or 0.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

------- Comment #12 from jason at gcc dot gnu dot org  2009-06-10 20:58 -------
Incidentally, the testcase can be simplified by removing the body of the copy
constructor, i.e. reducing it to just the declaration

  H (const H &h);

since it isn't actually called.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-06-10 20:58 -------
Well.  I see as final difference (no SRA vs. with SRA)

 <bb 2>:
   D.2249 = baz (); [return slot optimization]
-  D.2417_8 = D.2249.a;
-  g.a = D.2417_8;
-  D.2415_10 = &D.2417_8->k;
+  SR.101_9 = D.2249.a;
+  SR.102_31 = D.2249.p;
+  SR.103_32 = D.2249.n;
+  g.a = SR.101_9;
+  D.2415_10 = &SR.101_9->k;
   S<H>::bar (D.2415_10, &g);
-  if (D.2417_8 != 0B)
+  if (SR.101_9 != 0B)
     goto <bb 3>;
   else
     goto <bb 9>;

 <bb 3>:
-  D.2421_13 = D.2249.p;
-  if (D.2421_13 != 0B)
+  if (SR.102_31 != 0B)
     goto <bb 4>;
   else
     goto <bb 5>;

 <bb 4>:
-  D.2422_15 = D.2249.n;
-  D.2421_13->n = D.2422_15;
+  SR.102_31->n = SR.103_32;
   goto <bb 6>;

etc.

So you say that

   D.2249 = baz (); [return slot optimization]
-  D.2417_8 = D.2249.a;
-  g.a = D.2417_8;

makes D.2249.a escape and thus

   S<H>::bar (D.2415_10, &g);

is allowed to modify D.2249.a because D.2249.a->... may point to D.2249
itself?

If

  D.2249 = baz (); [return slot optimization]

makes D.2249 escape then this is a bug in both points-to analysis and
addressability analysis (the C++ FE should then make sure to set
TREE_ADDRESSABLE on D.2249 as well if it doesn't do so already).


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2009-06-10 21:27 -------
The gimplifier sees:
TARGET_EXPR <D.2252, <<< Unknown tree: aggr_init_expr
  3
  baz
  D.2252 >>>
>;
and:
    arg 0 <var_decl 0x7ffff2d7f280 D.2252 type <record_type 0x7ffff2d61780 H>
        addressable ignored BLK file pr40389.C line 67 col 12 size <integer_cst
0x7ffff2e136c0 192> unit size <integer_cst 0x7ffff2e13660 24>
        align 64 context <function_decl 0x7ffff2d80100 main>>
and
<record_type 0x7ffff2d61780 H addressable needs-constructing type_1 type_4
type_5 type_6 BLK...
(i.e. both are addressable).
Yes, as I said earlier, I think we should handle
D.2249 = baz (); [return slot optimization]
as taking address of D.2249, at least if it has TREE_ADDRESSABLE type.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2009-06-10 21:28 -------
Shorter testcase:
template <typename V> struct S
{
  V *f, *l;
  __attribute__ ((noinline)) S (void) { f = 0, l = 0; }
  void foo (V *x)
  {
    if (x->p != 0)
      x->p->n = x->n;
    else
      f = x->n;
    if (x->n != 0)
      x->n->p = x->p;
    else
      l = x->p;
  }
  __attribute__ ((noinline)) void bar (V *x)
  {
    x->n = 0;
    x->p = l;
    if (l != 0)
      l->n = x;
    else
      f = x;
    l = x;
  }
};

struct H;

struct A
{
  S <H> k;
};

struct H
{
  A *a;
  H *p, *n;
  __attribute__ ((noinline)) H (void) { p = 0, n = 0, a = 0; }
  __attribute__ ((noinline)) H (A *b) : a (b)
  {
    p = n = 0;
    if (a != 0)
      a->k.bar (this);
  }
  ~H (void) { if (a != 0) a->k.foo (this); }
  H &operator= (const H &o)
  {
    a = o.a;
    if (a != 0)
      a->k.bar (this);
    return *this;
  }
};

__attribute__ ((noinline))
H baz (void)
{
  return H (new A);
}

H g;

int
main (void)
{
  g = baz ();
  if (g.a->k.f != &g)
    __builtin_abort ();
  return 0;
}


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2009-06-10 21:29 -------
In which case the following will fix it (provided the C++ FE sets the
TREE_ADDRESSABLE flag)

Index: gimple.c
===================================================================
--- gimple.c    (revision 148325)
+++ gimple.c    (working copy)
@@ -3264,6 +3264,9 @@ walk_stmt_load_store_addr_ops (gimple st
          && TREE_CODE (gimple_call_chain (stmt)) == ADDR_EXPR)
        ret |= visit_addr (stmt, TREE_OPERAND (gimple_call_chain (stmt), 0),
                           data);
+      if (visit_addr
+         && gimple_call_return_slot_opt_p (stmt))
+       ret |= visit_addr (stmt, gimple_call_lhs (stmt), data);
     }
   else if (gimple_code (stmt) == GIMPLE_ASM)
     {
Index: tree-ssa-operands.c
===================================================================
--- tree-ssa-operands.c (revision 148325)
+++ tree-ssa-operands.c (working copy)
@@ -1035,6 +1035,10 @@ parse_ssa_operands (gimple stmt)
          start = 1;
        }

+      if (code == GIMPLE_CALL
+         && gimple_call_return_slot_opt_p (stmt))
+       mark_address_taken (gimple_call_lhs (stmt));
+
       for (i = start; i < gimple_num_ops (stmt); i++)
        get_expr_operands (stmt, gimple_op_ptr (stmt, i), opf_use);



-- 

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|2009-06-10 19:37:07         |2009-06-10 21:29:08
               date|                            |


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

[Bug c++/40389] optimizer bug (possibly)

[jason at redhat dot com]

------- Comment #17 from jason at redhat dot com  2009-06-12 17:30 -------
Subject: Re:  optimizer bug (possibly)

On 06/10/2009 05:27 PM, jakub at gcc dot gnu dot org wrote:
> Yes, as I said earlier, I think we should handle
> D.2249 = baz (); [return slot optimization]
> as taking address of D.2249, at least if it has TREE_ADDRESSABLE type.

No; it should only do this if 'this' escapes from a constructor for the 
type, as in this testcase when it's passed to bar.  This should be a 
small subset of TREE_ADDRESSABLE types.

Your reduced testcase removes the copy constructor entirely, which makes 
the program incorrect; my earlier suggestion was to just remove its 
body, which would produce a link error if it's invoked (as it shouldn't, 
as we elide the copy) rather than invalid code.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2009-06-12 18:58 -------
Often you don't see the constructor body, but still even if the constructor
isn't defined in the current CU this address can be taken there.
Also, even if the ctor doesn't remember the address of this, IMHO because of
NRV optimization anything else can.  Say if the ctor doesn't call a->k.bar
(this);, but baz is:
__attribute__ ((noinline))
H baz (void)
{
  H ret = new A;
  if (ret.a)
    ret.a->k.bar (&ret);
  return ret;
}
then it is baz that actually takes address of the temporary variable, not the
ctor.  And, similarly to the ctor, baz doesn't have to be defined in the
current CU.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2009-06-13 17:02 -------
Subject: Bug 40389

Author: rguenth
Date: Sat Jun 13 17:02:17 2009
New Revision: 148458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148458
Log:
2009-06-13  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/40389
        * tree-predcom.c (should_unroll_loop_p): Remove.
        (tree_predictive_commoning_loop): Use can_unroll_loop_p.

        * gfortran.fortran-torture/compile/pr40421.f: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr40421.f
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-predcom.c


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2009-06-13 19:30 -------
So, if I see correctly the issue only manifests itself if we elide the copy?
The C++ FE seems to unconditionally set TREE_ADDRESSABLE on the LHS.

Stripping down the fix to only apply if TREE_ADDRESSABLE is set still causes
some missed optimization opportunities, for example for
g++.dg/tree-ssa/pr8781.C


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2009-06-13 22:58 -------
Subject: Bug 40389

Author: rguenth
Date: Sat Jun 13 22:58:13 2009
New Revision: 148462

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148462
Log:
2009-06-14  Richard Guenther  <rguenther@suse.de>

        PR middle-end/40389
        * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call
        has its address taken if NRV was applied and it is addressable.
        * tree-ssa-structalias.c (get_constraint_for_address_of): New
        function split out from ...
        (get_constraint_for_1): ... here.
        (handle_rhs_call): Use it to mark the return slot escaped if
        it is addressable and NRV was applied.

        * g++.dg/torture/pr40389.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr40389.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2009-06-13 22:58 -------
Fixed on trunk.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.3.3 4.4.0 4.5.0           |4.3.3 4.4.0
      Known to work|                            |4.5.0


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

[Bug c++/40389] optimizer bug (possibly)

[jason at redhat dot com]

------- Comment #24 from jason at redhat dot com  2009-06-14 15:40 -------
Subject: Re:  optimizer bug (possibly)

On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote:
>          (handle_rhs_call): Use it to mark the return slot escaped if
>          it is addressable and NRV was applied.

Here too, of course.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[jason at redhat dot com]

------- Comment #23 from jason at redhat dot com  2009-06-14 15:39 -------
Subject: Re:  optimizer bug (possibly)

On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote:
>          * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call
>          has its address taken if NRV was applied and it is addressable.

This should check TREE_ADDRESSABLE on the type rather than the variable.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenther at suse dot de]

------- Comment #25 from rguenther at suse dot de  2009-06-14 15:41 -------
Subject: Re:  optimizer bug (possibly)

On Sun, 14 Jun 2009, jason at redhat dot com wrote:

> ------- Comment #23 from jason at redhat dot com  2009-06-14 15:39 -------
> Subject: Re:  optimizer bug (possibly)
> 
> On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote:
> >          * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call
> >          has its address taken if NRV was applied and it is addressable.
> 
> This should check TREE_ADDRESSABLE on the type rather than the variable.

For what middle-end semantics?  I check TREE_ADDRESSABLE to leave it
completely to the frontend if the LHS is addressable or not.  So
the frontend should only set it if the type is TREE_ADDRESSABLE then.

Richard.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2009-06-17 10:29 -------
Subject: Bug 40389

Author: rguenth
Date: Wed Jun 17 10:29:22 2009
New Revision: 148597

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148597
Log:
2009-06-17  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/40389
        * tree-ssa-structalias.c (handle_rhs_call): Restrict NRV case
        to addressable types.
        * gimple.c (walk_stmt_load_store_addr_ops): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c
    trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #27 from rguenth at gcc dot gnu dot org  2009-06-17 10:34 -------
Subject: Bug 40389

Author: rguenth
Date: Wed Jun 17 10:33:31 2009
New Revision: 148601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148601
Log:
2009-06-17  Richard Guenther  <rguenther@suse.de>

        PR middle-end/40389
        * tree-ssa-operands.c (parse_ssa_operands): Add NRV results
        to the addresses taken bitmap.

        * g++.dg/torture/pr40389.C: New testcase.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr40389.C
Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/gcc/tree-ssa-operands.c


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2009-06-17 12:03 -------
Subject: Bug 40389

Author: rguenth
Date: Wed Jun 17 12:03:08 2009
New Revision: 148604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148604
Log:
2009-06-17  Richard Guenther  <rguenther@suse.de>

        PR middle-end/40389
        * tree-ssa-operands.c (get_modify_stmt_operands): Add NRV
        results to the addresses taken bitmap.
        * tree-scalar-evolution.c (scev_const_prop): Do not insert
        incomplete stmts into the instruction stream.

        * g++.dg/torture/pr40389.C: New testcase.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr40389.C
Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/tree-scalar-evolution.c
    branches/gcc-4_3-branch/gcc/tree-ssa-operands.c


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

------- Comment #29 from rguenth at gcc dot gnu dot org  2009-06-17 12:04 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|4.5.0                       |4.3.4 4.4.1 4.5.0
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.4


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