[Bug middle-end/44164] New: [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function

[Bug middle-end/44164] New: [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function

[maxime at altribe dot org]

Using Boost.Bind/Boost.Function triggers what seems to be an aliasing bug with
G++ 4.5.0. The minimal test case (including Boost.Bind and Boost.Function) is
attached.

It works and no errors are detected by valgrind with either flags :
 -O0
 -O1
 -O2 -fno-inline
 -O2 -fno-strict-aliasing
 -Os

It crashes whith either flags and valgrind detects invalid reads :
 -02
 -O3

Everything works fine with gcc version 4.4.3 20100316.

There are no warnings using '-W -Wall -Wextra'.

Original bug report to boost mailing list :
 http://lists.boost.org/boost-users/2010/05/59020.php


-- 
           Summary: [4.5.0] Aliasing bug triggered by
                    Boost.Bind/Boost.Function
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: maxime at altribe dot org
 GCC build triplet: ../configure --prefix=/usr --enable-
                    languages=c,c++,fortran,objc
  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=44164

[Bug middle-end/44164] [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function

[maxime at altribe dot org]

------- Comment #1 from maxime at altribe dot org  2010-05-17 08:31 -------
Created an attachment (id=20677)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20677&action=view)
Test case including Boost.Bind and Boost.Function.

I had to gzip the .ii file because of size limit.


-- 


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-17 09:39 -------
It's not a dup of PR42834 (but it might be the same issue as PR42832 which
was a libstdc++ bug or a frontend bug).

It happens to work on trunk, so it might also be a dup of PR43987 (though
unlikely), rather different inlining might have made the bug latent.

I can confirm the observed effect.  I didn't investigate on whether this
is a bug in boost or not (we're changing our minds on what is valid and
what not all the time anyway).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.5.0
      Known to work|                            |4.4.3 4.6.0
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-17 09:39:31
               date|                            |
            Summary|[4.5.0] Aliasing bug        |[4.5 Regression] Aliasing
                   |triggered by                |bug triggered by
                   |Boost.Bind/Boost.Function   |Boost.Bind/Boost.Function
   Target Milestone|---                         |4.5.1


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-17 09:44 -------
The boost folks may be able to tell if they at any place copy a
function_buffer object via the assignment operator.

I see they also have funny stuff like get_vtable() and are playing with
typeinfos.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[maxime at altribe dot org]

------- Comment #4 from maxime at altribe dot org  2010-05-17 13:10 -------
(In reply to comment #3)
> The boost folks may be able to tell if they at any place copy a
> function_buffer object via the assignment operator.

It seems so. From Peter Dimov :

> [...] after stepping through the code, it turns out that function_buffer is
> indeed assigned directly, due to the fact that __has_trivial_copy and
> __has_trivial_destructor report true for the stored function object.


-- 


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-05-17 15:50 -------
(In reply to comment #4)
> (In reply to comment #3)
> > The boost folks may be able to tell if they at any place copy a
> > function_buffer object via the assignment operator.
> 
> It seems so. From Peter Dimov :
> 
> > [...] after stepping through the code, it turns out that function_buffer is
> > indeed assigned directly, due to the fact that __has_trivial_copy and
> > __has_trivial_destructor report true for the stored function object.

Which means that it is either a C++ frontend bug not protecting this
aggregate assignment properly or a bug in Boost as the functor type stored
to function_buffer is not a member of the union.  The functor types
are for example seen in

            const functor_type* in_functor =
              reinterpret_cast<const functor_type*>(&in_buffer.data);
            new ((void*)&out_buffer.data) functor_type(*in_functor);

but functor_type (a template param) is not a member of said union.

People were arguing that the char member in the union should make this
valid, but nothing in the C++ frontend communicates that to the
alias analysis stage.  People also were arguing only a character
array member would qualify, possibly covering the whole union in size.

A workaround for boost can be constructed following the fix for PR42832.
Due to an unrelated bug using memcpy for the assingment won't work.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2010-05-17 09:39:31         |2010-05-17 15:50:41
               date|                            |


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-05-17 15:57 -------
Basically the middle-end sees this the same as

  int i = 1, j;
  float *p = new (&i) float(0.0);
  j = i;
  return *reinterpret_cast<float *>(&j);

and you expect to return 0.0.


-- 


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[pdimov at gmail dot com]

------- Comment #7 from pdimov at gmail dot com  2010-05-17 19:10 -------
(In reply to comment #6)
> Basically the middle-end sees this the same as
>   int i = 1, j;
>   float *p = new (&i) float(0.0);
>   j = i;
>   return *reinterpret_cast<float *>(&j);
> and you expect to return 0.0.

The int/float example does violate the aliasing rules, but I don't think that
it properly describes what's happening.

I see it more like a combination of the following two examples:

#include <iostream>

struct X
{
    char data[ sizeof( float ) ];
};

int main()
{
    X x1;
    new( &x1.data ) float( 3.14f );

    X x2 = x1;

    std::cout << *(float const*)&x2.data << std::endl;
}

and

#include <iostream>

union Y
{
    int i;
    float f;
};

int main()
{
    Y y1;
    y1.f = 3.14f;

    Y y2 = y1;

    std::cout << y2.f << std::endl;
}

I don't think either of them violates the standard.


-- 

pdimov at gmail dot com changed:

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


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2010-05-17 19:17 -------
The first example I think does as there is no way to "transfer" the dynamic
type via the struct copy.  The second one does not as the union still has a
field that is float and it is only unspecified behavior if you access the other
field in the union (IIRC).


-- 


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[pdimov at gmail dot com]

------- Comment #9 from pdimov at gmail dot com  2010-05-17 20:12 -------
But the standard says in [basic.types] that "For any trivially copyable type T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making
up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as
obj1."

"float" is a trivially copyable type. Copying X results in copying the bytes of
X::data (because the default copy constructor of a class does a memberwise
copy, and the default copy constructor of an array does an elementwise copy).
Therefore, the underlying bytes of the object of type float, initialized at
x1.data, are copied into x2.data, which then must, if interpreted as a float,
hold the same value as the original object.


-- 


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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-05-18 14:58 -------
(In reply to comment #9)
> But the standard says in [basic.types] that "For any trivially copyable type T,
> if two pointers to T point to distinct T objects obj1 and obj2, where neither
> obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making
> up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as
> obj1."

Yep.  But an assignment is not a byte-copy and exactly the assignment is
what invokes the undefined behavior (not the subsequent access).

So,

struct X
{
    char data[ sizeof( float ) ];
};

int main()
{
    X x1;
    new( &x1.data ) float( 3.14f );

    X x2 = x1;


GCC sees this as reading the float object you made live in x1.data via
an lvalue of type X and thus decides that the float object is unused
and removes it.


-- 

rguenth 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=44164

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2010-05-18 15:00 -------
(In reply to comment #10)
> (In reply to comment #9)
> > But the standard says in [basic.types] that "For any trivially copyable type T,
> > if two pointers to T point to distinct T objects obj1 and obj2, where neither
> > obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making
> > up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as
> > obj1."
> 
> Yep.  But an assignment is not a byte-copy and exactly the assignment is
> what invokes the undefined behavior (not the subsequent access).
> 
> So,
> 
> struct X
> {
>     char data[ sizeof( float ) ];
> };
> 
> int main()
> {
>     X x1;
>     new( &x1.data ) float( 3.14f );
> 
>     X x2 = x1;
> 
> 
> GCC sees this as reading the float object you made live in x1.data via
> an lvalue of type X and thus decides that the float object is unused
> and removes it.

Oh, and

 "float" is a trivially copyable type. Copying X results in copying the bytes
of
 X::data (because the default copy constructor of a class does a memberwise
 copy, and the default copy constructor of an array does an elementwise copy).
 Therefore, the underlying bytes of the object of type float, initialized at
 x1.data, are copied into x2.data, which then must, if interpreted as a float,
 hold the same value as the original object.

is not what the C++ frontend does.  It emits the assignment literally:

  <<cleanup_point <<< Unknown tree: expr_stmt
  (void) (x2 = TARGET_EXPR <D.21180, x1>) >>>
>>;

gimplified to

    x2 = x1;


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2010-05-18 15:02 -------
Making this a C++ frontend bug.  The only way to avoid expanding the copy
to a loop is by using memcpy which will then run into PR42834.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org
          Component|middle-end                  |c++


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[pluto at agmk dot net]

------- Comment #13 from pluto at agmk dot net  2010-05-18 20:57 -------
btw. the boost::optional uses char-based storage and cast &storage
-> void* -> some_type* via address() and get_object() methods.
it looks like aliasing violation too.


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

-- 

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|2010-05-17 15:50:41         |2010-05-19 22:15:45
               date|                            |


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

------- Comment #14 from jason at gcc dot gnu dot org  2010-05-19 22:53 -------
In C++, an assignment of a union is defined to be equivalent to a byte copy:

12.8/32 "The implicitly-defined copy assignment operator for a union X copies
the object representation (3.9) of X."

3.9/4 "The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T)."


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

------- Comment #15 from jason at gcc dot gnu dot org  2010-05-20 05:35 -------
Giving all unions alias set 0 doesn't fix the testcase.  This surprises me,
since I thought that the problem was with the union assignment

          this->functor = f.functor;

in assign_to_own.  Giving alias set 0 to all classes with a member or base of
alias set 0 also doesn't fix the testcase.  Giving alias set 0 to all classes
does fix the testcase.


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenther at suse dot de]

------- Comment #16 from rguenther at suse dot de  2010-05-20 11:48 -------
Subject: Re:  [4.5 Regression] Aliasing bug triggered by
 Boost.Bind/Boost.Function

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> ------- Comment #15 from jason at gcc dot gnu dot org  2010-05-20 05:35 -------
> Giving all unions alias set 0 doesn't fix the testcase.  This surprises me,
> since I thought that the problem was with the union assignment
> 
>           this->functor = f.functor;
> 
> in assign_to_own.  Giving alias set 0 to all classes with a member or base of
> alias set 0 also doesn't fix the testcase.  Giving alias set 0 to all classes
> does fix the testcase.

Ok, I'll try to pin-point the exact problem.


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2010-05-20 13:24 -------
It is actually the scheduler that breaks the testcase.  Easier to look at
is -O2 -fwhole-program.  -fno-schedule-insns2 fixes it (as well as
-fno-tree-pre
or -fno-tree-dominator-opts, both of which are necessary to produce the
input to the scheduler).


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

------- Comment #18 from jason at gcc dot gnu dot org  2010-05-20 14:00 -------
Unassigning myself.


-- 

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=44164

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

------- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 14:01 -------
And changing component to rtl-opt.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |rtl-optimization


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2010-05-25 13:56 -------
-fsched2-use-superblocks also fixes it.

-fdbg-cnt=sched_region:65 is broken, -fdbg-cnt=sched_region:64 works for
a simplified testcase tail:

int bmi_get(const int* id)
{
  if (*id != 42)
    __builtin_abort();

  return 0;
}

int main()
{
  int id = 42;

  typedef boost::function<int ()> func_t;

  func_t f = boost::bind(&bmi_get, &id);
  func_t g = f;
  g();

  return 0;
}

Assembler difference:

--- /tmp/gtest.s.ok     2010-05-25 15:51:19.000000000 +0200
+++ /tmp/gtest.s.broken 2010-05-25 15:51:30.000000000 +0200
@@ -825,21 +825,21 @@
        call    _ZN5boost6detail8function16has_empty_targetEz
        testb   %al, %al
        jne     .L93
+       movq    112(%rsp), %rdx
        leaq    96(%rsp), %rbx
-       movq    $_Z7bmi_getPKi, 104(%rsp)
-       movq    %rbp, 16(%rbx)
        movl   
$_ZZN5boost9function0IiE9assign_toINS_3_bi6bind_tIiPFiPKiENS3_5l
ist1INS3_5valueIPiEEEEEEEEvT_E13stored_vtable, %eax
        orq     $1, %rax
-       movq    %rax, 96(%rsp)
-       movq    %rax, 64(%rsp)
+       movq    $_Z7bmi_getPKi, 104(%rsp)
        movq    $_Z7bmi_getPKi, 72(%rsp)
-       movq    112(%rsp), %rdx
+       movq    %rbp, 16(%rbx)
+       leaq    64(%rsp), %rbp
+       movq    %rax, 96(%rsp)
        movq    %rdx, 80(%rsp)
        movq    120(%rsp), %rdx
-       movq    %rdx, 88(%rsp)
+       movq    %rax, 64(%rsp)
        andq    $-2, %rax
-       leaq    64(%rsp), %rbp
        leaq    8(%rbp), %rdi
+       movq    %rdx, 88(%rsp)
 .LEHB15:
        call    *8(%rax)
 .LEHE15:

Still can't see where that is broken ... :/


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-05-25 14:57 -------
We're exchanging

        movq    112(%rsp), %rdx

and

        leaq    96(%rsp), %rbx
        movq    %rbp, 16(%rbx)

which is broken.

(insn 565 18 20 3 /usr/include/boost/function/function_template.hpp:566 (set
(reg/f:DI 3 bx [242])
        (plus:DI (reg/f:DI 7 sp)
            (const_int 96 [0x60]))) 248 {*lea_1} (nil))

(insn 23 21 24 3 gtest.cc:21 (set (mem/s/f:DI (plus:DI (reg/f:DI 3 bx [242])
                (const_int 16 [0x10])) [20 D.60304_20->l_.D.57654.a1_.t_+0 S8
A64])
        (reg/f:DI 6 bp [140])) 89 {*movdi_1_rex64} (expr_list:REG_DEAD
(reg/f:DI 6 bp [140])
        (nil)))

(insn 39 38 40 3 /usr/include/boost/function/function_template.hpp:886 (set
(reg:DI 1 dx [orig:146 f.D.56107.D.55977.functor+8 ] [146])
        (mem/s/c:DI (plus:DI (reg/f:DI 7 sp)
                (const_int 112 [0x70])) [9 f.D.56107.D.55977.functor+8 S8
A64])) 89 {*movdi_1_rex64} (expr_list:REG_EQUIV (mem/s/c:DI (plus:DI (reg/f:DI
7 sp)
                (const_int 112 [0x70])) [9 f.D.56107.D.55977.functor+8 S8 A64])
        (nil)))

Relevant MEM_ATTRs are

  [20 D.60304_20->l_.D.57654.a1_.t_+0 S8 A64]
  [9 f.D.56107.D.55977.functor+8 S8 A64]

  struct bind_t * D.60304;
  struct bind_t f;
  struct func_t f;

  D.60304_20 = (struct bind_t *) &f.D.56107.D.55977.functor.data;
  D.60304_20->l_.D.57654.a1_.t_ = &id;
...
  g.D.56107.D.55977.functor = f.D.56107.D.55977.functor;

which we disambiguate via the TBAA tree oracle as the pointed-to type
by D.60304_20 is bind_t and has alias-set 21 which is not a subset of
alias-set 5, the alias-set of f.  This particular disambiguation would
be fixed by backporting the alias_set_subset_of change.  Then we
disambiguate via access-path based disambiguation.


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-05-25 15:28 -------
I have some patches.


-- 

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-05-19 22:15:45         |2010-05-25 15:28:49
               date|                            |


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2010-05-26 10:30 -------
Subject: Bug 44164

Author: rguenth
Date: Wed May 26 10:30:31 2010
New Revision: 159861

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159861
Log:
2010-05-26  Richard Guenther  <rguenther@suse.de>

        PR rtl-optimization/44164
        * tree-ssa-alias.c (aliasing_component_refs_p): Fix the
        no-common access-path disambiguation.
        (indirect_ref_may_alias_decl_p): Adjust.
        (indirect_refs_may_alias_p): Likewise.
        (refs_may_alias_p_1): Likewise.

        * gcc.c-torture/execute/pr44164.c: New testcase.
        * g++.dg/tree-ssa/pr13146.C: Adjust.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr44164.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/tree-ssa/pr13146.C
    trunk/gcc/tree-ssa-alias.c


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2010-05-26 11:46 -------
Subject: Bug 44164

Author: rguenth
Date: Wed May 26 11:46:01 2010
New Revision: 159866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159866
Log:
2010-05-26  Richard Guenther  <rguenther@suse.de>

        PR rtl-optimization/44164
        * tree-ssa-alias.c (aliasing_component_refs_p): Fix the
        no-common access-path disambiguation.
        (indirect_ref_may_alias_decl_p): Adjust.
        (indirect_refs_may_alias_p): Likewise.
        (refs_may_alias_p_1): Likewise.

        * gcc.c-torture/execute/pr44164.c: New testcase.
        * g++.dg/tree-ssa/pr13146.C: Adjust.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44164.c
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/g++.dg/tree-ssa/pr13146.C
    branches/gcc-4_5-branch/gcc/tree-ssa-alias.c


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2010-05-26 11:46 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jamborm at gcc dot gnu dot org]

------- Comment #26 from jamborm at gcc dot gnu dot org  2010-06-07 16:51 -------
*** Bug 44406 has been marked as a duplicate of this bug. ***


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |torbenh at users dot
                   |                            |sourceforge dot net


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