[Bug ipa/65270] New: [5 regression] ICF needs to match TYPE attributes on memory accesses

[Bug ipa/65270] New: [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

            Bug ID: 65270
           Summary: [5 regression] ICF needs to match TYPE attributes on
                    memory accesses
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org

As discussed here https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00028.html

$ more t.c
struct a 
{
  int a[100000];
}
__attribute__ ((aligned (32)));
struct b 
{
  int a[100000];
};
t2(struct a *a)
{
  int i;
  for (i=0;i<100000;i++)
    a->a[i]++;
}
t(struct b *a)
{
  int i;
  for (i=0;i<100000;i++)
    a->a[i]++;
}
$ ./xgcc -B ./ -O3 t.c -flto -c  -fno-inline 
t.c:10:1: warning: return type defaults to �int� [-Wimplicit-int]
 t2(struct a *a)
 ^
t.c:16:1: warning: return type defaults to �int� [-Wimplicit-int]
 t(struct b *a)
 ^
$ ./xgcc -B ./ -O3 t.o -flto  -r -nostdlib
$ objdump a.out -d

a.out:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <t2>:
   0:   48 8d 87 80 1a 06 00    lea    0x61a80(%rdi),%rax
   7:   66 0f 6f 0d 00 00 00    movdqa 0x0(%rip),%xmm1        # f <t2+0xf>
   e:   00 
   f:   90                      nop
  10:   48 83 c7 10             add    $0x10,%rdi
  14:   66 0f 6f 47 f0          movdqa -0x10(%rdi),%xmm0
  19:   66 0f fe c1             paddd  %xmm1,%xmm0
  1d:   0f 29 47 f0             movaps %xmm0,-0x10(%rdi)
  21:   48 39 c7                cmp    %rax,%rdi
  24:   75 ea                   jne    10 <t2+0x10>
  26:   f3 c3                   repz retq 
  28:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
  2f:   00 

0000000000000030 <t>:
  30:   e9 00 00 00 00          jmpq   35 <t+0x5>

The functions t and t2 are incorrectly unified.
>From gcc-bugs-return-478916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 02 01:03:13 2015
Return-Path: <gcc-bugs-return-478916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 102431 invoked by alias); 2 Mar 2015 01:03:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 102359 invoked by uid 48); 2 Mar 2015 01:03:08 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
Date: Mon, 02 Mar 2015 01:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65233-4-X4oJWS9bns@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65233-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65233-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00060.txt.bz2
Content-length: 189

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide233

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yep, this seems resonable patch to me. It is OK if it passes testing.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-03-02
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
In theory comparing the object alignment with sth like

      unsigned int align1, align2;
      unsigned HOST_WIDE_INT tem;
      get_object_alignment_1 (t1, &align1, &tem);
      get_object_alignment_1 (t2, &align2, &tem);
      if (align1 != align2)
        return return_false_with_msg ("different access alignment");

should work, but in this case with variable offset we don't represent
"unknown misalign offset" and thus fail to see the difference here.
Thus we have to compare alignment of the base object here (but then
not that from ao_ref_base because that's too aggressive in stripping
MEM_REFs).

I have a patch.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Mar  2 14:31:46 2015
New Revision: 221117

URL: https://gcc.gnu.org/viewcvs?rev=221117&root=gcc&view=rev
Log:
2015-03-02  Richard Biener  <rguenther@suse.de>

    PR ipa/65270
    * ipa-icf-gimple.c: Include builtins.h.
    (func_checker::compare_memory_operand): Compare base alignment.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-icf-gimple.c

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Thanks for looking into this! I think this was just the most obvoious of TYPE
flags. Some more we need to look into:

Is the alias class compare enough to handle TYPE_RESTRICT?

We probably want to match TYPE_ADDR_SPACE of accesses as that affect codegen?

We apparently need to match TYPE_ATTRIBUTES on functions, because we check that
flags on calees so we can not freely redirect them. Will fix that.

Also I think TYPE_STRING_FLAG may affect expand_builtin_classify_type that
probably ought to be done at folding time during early opts?

TYPE_NEEDS_CONSTRUCTING is used by ipa-pure-const but I think the use is wrong
(i.e. if decl needs to be constructed we will drop the readonly flag)

TYPE_NONALIASED_COMPONENT seems to affect alias.c in some way.

TYPE_FINAL_P also can not be mixed in virtual tables.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 2 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Thanks 
> for looking into this! I think this was just the most obvoious of TYPE 
> flags. Some more we need to look into:
> 
> Is the alias class compare enough to handle TYPE_RESTRICT?

No.  But you can't compare restrict qualification by looking at a memory
reference pair from function A and function B.  You'd have to compare
all data dependences somehow.

You could get some cases by comparing function parameter types specially
(but global vars also have an issue, as well as decl-by-reference
aggregate parameters).

> We probably want to match TYPE_ADDR_SPACE of accesses as that affect codegen?

Well, that should be handled already by comparing MEM_REF operands
via types_compatible_p.

> We apparently need to match TYPE_ATTRIBUTES on functions, because we 
> check that flags on calees so we can not freely redirect them. Will fix 
> that.
>
> Also I think TYPE_STRING_FLAG may affect expand_builtin_classify_type that
> probably ought to be done at folding time during early opts?

classify-type is folded by frontends I think

> TYPE_NEEDS_CONSTRUCTING is used by ipa-pure-const but I think the use is 
> wrong (i.e. if decl needs to be constructed we will drop the readonly 
> flag)

Also sounds frontendish or gimplifyish

> TYPE_NONALIASED_COMPONENT seems to affect alias.c in some way.

Yes.  Similar to DECL_NONADDRESSABLE.  Both are used only by Ada.

> TYPE_FINAL_P also can not be mixed in virtual tables.

It seems to me that ICF isn't quite ready for prime time.  Let's disable
it by default for now, ok?

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

howarth at bromo dot med.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at bromo dot med.uc.edu

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to rguenther@suse.de from comment #6)
> It seems to me that ICF isn't quite ready for prime time.  Let's disable
> it by default for now, ok?

Do you mean ship 5.0 with ICF disabled by default?

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On March 3, 2015 4:08:17 PM CET, "howarth at bromo dot med.uc.edu"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
>
>howarth at bromo dot med.uc.edu changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>        CC|                            |howarth at bromo dot med.uc.edu
>
>--- Comment #7 from howarth at bromo dot med.uc.edu ---
>(In reply to rguenther@suse.de from comment #6)
>> It seems to me that ICF isn't quite ready for prime time.  Let's
>disable
>> it by default for now, ok?
>
>Do you mean ship 5.0 with ICF disabled by default?

Yes.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Lets reopen this.  I agree with other type flags - they seem safe except for
TYPE_ATTRIBUTES of functions I will add compare of today.

> No.  But you can't compare restrict qualification by looking at a memory
> reference pair from function A and function B.  You'd have to compare
> all data dependences somehow.
>
> You could get some cases by comparing function parameter types specially
> (but global vars also have an issue, as well as decl-by-reference
> aggregate parameters).

Would it be enough to
 - require match on arguments/return value types (that should handle function
parameters as well as 
 - require match on all global variable types

> It seems to me that ICF isn't quite ready for prime time.  Let's disable
> it by default for now, ok?

I also read the discussion on IRC and discussed with Jeff.
ICF has triggered interesting issues in alias/thunks areas. For a first time we
output a lot of non-MI thunks on main targets and expand_thunk was getting
things wrong in a nasty ways.  ICF also produce a lot of aliases and excercise
symbol table code otherwise rarely used. Here I think it is valuable we fixed
those bugs that were semi-latent for years.  I believe we are approaching
steady state - at the moment we do not have any other ICF related PR open. Jeff
suggested to wait 48 hours.

This PR is a result of my code audit I did over weekend. I fully leave the
decision with you. I agree ICF is causing a lot of issues late in release and
disabling it is a safe option. On the other hand I would be happy to work to
get it fixed and working - it is quite useful optimization.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Hi,
while looking for a testcase that would trigger with tree-tail-merge (because
gimple-fold seems to also miss MEM_REF merging) I noticed following oddity:

struct a 
{
  int a[100000];
};
typedef struct a b __attribute__ ((aligned (32)));
typedef struct a c __attribute__ ((aligned (8)));
typedef struct a d __attribute__ ((aligned (32)));

__attribute__ ((used))
t(b *a, int aligned, b *d)
{
  int i,v;
        c *ptr = a;
  for (i=0;i<100000;i++)
    {
        ptr->a[i]++;
    }
}
main()
{
}

here the loop gets vectorized with assumed alignmen 32.
Changing declaretion to:
t(c *a, int aligned, b *d)
produces correct 8 byte alignment loop.
Alignment of the type of variable A shall not be used.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #9)
> Lets reopen this.  I agree with other type flags - they seem safe except for
> TYPE_ATTRIBUTES of functions I will add compare of today.
> 
> > No.  But you can't compare restrict qualification by looking at a memory
> > reference pair from function A and function B.  You'd have to compare
> > all data dependences somehow.
> >
> > You could get some cases by comparing function parameter types specially
> > (but global vars also have an issue, as well as decl-by-reference
> > aggregate parameters).
> 
> Would it be enough to
>  - require match on arguments/return value types (that should handle
> function parameters as well as 
>  - require match on all global variable types

It would be a start, but no - consider early inlining and

static inline int foo (int * restrict p, int * restrict q) { ... }
static inline int foo2 (int *p, int *q) { same as foo }
int bar (int *p, int *q)
{
  return foo (p, q);
}
int bar2 (int *p, int *q)
{
  return foo2 (p, q);
}

where actual code generation difference would only show up in the main
optimization queue.

With the present implementation you'd have to compare MR_DEPENDENCE_CLIQUE
and MR_DEPENDENCE_BASE for MEM_REFs/TARGET_MEM_REFs.  Of course literally
comparing them isn't really correct (though if they are equal you are safe).

So - compare TYPE_MAIN_VARIANT of global var and function parameter types
and MR_DEPENDENCE_* on MEM_REFs should be enough to catch restrict
differences (fingers crossing ;)).

I'll try to cook up a patch.

> > It seems to me that ICF isn't quite ready for prime time.  Let's disable
> > it by default for now, ok?
> 
> I also read the discussion on IRC and discussed with Jeff.
> ICF has triggered interesting issues in alias/thunks areas. For a first time
> we output a lot of non-MI thunks on main targets and expand_thunk was
> getting things wrong in a nasty ways.  ICF also produce a lot of aliases and
> excercise symbol table code otherwise rarely used. Here I think it is
> valuable we fixed those bugs that were semi-latent for years.  I believe we
> are approaching steady state - at the moment we do not have any other ICF
> related PR open. Jeff suggested to wait 48 hours.
> 
> This PR is a result of my code audit I did over weekend. I fully leave the
> decision with you. I agree ICF is causing a lot of issues late in release
> and disabling it is a safe option. On the other hand I would be happy to
> work to get it fixed and working - it is quite useful optimization.

Sure - it just seems with every change you introduce bootstrap failures
on some targets which is quite bad.  Let's hope things stabilize and please
no re-writes anymore.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 3 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Hi,
> while looking for a testcase that would trigger with tree-tail-merge (because
> gimple-fold seems to also miss MEM_REF merging) I noticed following oddity:
> 
> struct a 
> {
>   int a[100000];
> };
> typedef struct a b __attribute__ ((aligned (32)));
> typedef struct a c __attribute__ ((aligned (8)));
> typedef struct a d __attribute__ ((aligned (32)));
> 
> __attribute__ ((used))
> t(b *a, int aligned, b *d)
> {
>   int i,v;
>         c *ptr = a;
>   for (i=0;i<100000;i++)
>     {
>         ptr->a[i]++;
>     }
> }
> main()
> {
> }
> 
> here the loop gets vectorized with assumed alignmen 32.
> Changing declaretion to:
> t(c *a, int aligned, b *d)
> produces correct 8 byte alignment loop.
> Alignment of the type of variable A shall not be used.

Hmm.  And it's correctly handled by get_object_alignment.  It's
the vectorizer code that does odd things here.  I'll fix it.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34946&action=edit
patch

I am testing the following patch for the dependence info compare (not sure
where
the function parameter / global var type compare is located, so that part is
still missing).

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34949&action=edit
function parameter and variable part

I am testing that in addition.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, as variable merging always creates aliases accesses and their types remain
the same.  So we don't need any extra checks for merging globals here.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Richard,
thanks, I also think alias trick makes gloal vars safe for merging across
RESTRICT flags. 

One however needs to consider merging of items referring restricted vars.

const restrict int *a=&var;
const int *b = &var; 

const int **ptrs1={&a};
const int **ptrs2=[&b};

with -fmerge-all-constants we may merge ptrs1 and ptrs2 and, in the late
compilation, in turn fold expression "ptrs2[0]" into a restricted pointer to
var?

If this case is legit, the correct place to match RESTRICT flags is
compare_cgraph_references. We can also go with your patch that will make A and
B considered to be different and thus prevent merging PTRS1&PTRS2.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Thu Mar  5 00:10:29 2015
New Revision: 221199

URL: https://gcc.gnu.org/viewcvs?rev=221199&root=gcc&view=rev
Log:
     PR ipa/65270
    * ipa-icf.c (sem_item::compare_cgraph_references): Compare
    vtable references for their containing type.
    (sem_function::equals_wpa): Compare TYPE_RESTRICT
    and type attributes.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-icf.c

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Here is summary of my current understanding of remaining issues from my last
weekend's audit.

ICF specific:
 - ipa-icf-gimple.c needs to match dependence analysis
   Richard has propsed a patch for it, so I hope he will commit it tomorrow.
 - restrict flag may need to be matched when considering two references
   to variables being equal.
   Here I am waiting for Richards comment. I would propose matching restricts
in compare_cgraph_references same way as we now compare vtables.

non-ICF specific wrong codes
 - tree-vectorizer is picking up wrong alignment
 - fold-const.c's operands_equal_p probably needs same treatment for
   comparing mem-ref as ipa-icf-gimple has.  I think in all cases one can
   construct testcase where tree-tail-merge would produce same incorrect
   merging as ipa-icf does.

stuff that can wait for next stage1
 - ipa-pure-const is probably wrong to check TYPE_NEEDS_CONSTRUCTION flag
   (something to fix for next stage1)
 - expand_builtin_classify_type can probably be dropped, because
fold_classify_type prevails.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I tried to construct a testcase for __restrict__ case:
int var;
const int *varptr=&var;
const int *__restrict__ varptr2=&var;

 int *__restrict__ varptr3 = &var;
 int *__restrict__ varptr4 = &var;

int *
return_valptr(int i)
{
  return varptr[i];
}
int * __restrict__
return_valptr2(int i)
{
  return varptr2[i];
}
int
testrestrict ()
{
  int *ptr = return_valptr (0);
  *ptr = 0;
  *varptr3 = 1;
  return *ptr;
}
int
testrestrict2 ()
{
  int *ptr = return_valptr2 (0);
  *ptr = 0;
  *varptr3 = 1;
  return *ptr;
}
int
testrestrict4 ()
{
  *varptr4 = 0;
  *varptr3 = 1;
  return *varptr4;
}

Here I would like restrict2 to return uncondtional 0, because ptr is taken from
a restrict pointer in a global var.  For whatever reason this optimization is
not happening (it happens in testrestrict4). So perhaps we are safe to
completely ignore restircts on vars, because we never get the flag in through
folding.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Mar  5 08:43:13 2015
New Revision: 221204

URL: https://gcc.gnu.org/viewcvs?rev=221204&root=gcc&view=rev
Log:
2015-03-05  Richard Biener  <rguenther@suse.de>

    PR ipa/65270
    * ipa-icf-gimple.c (func_checker::compare_memory_operand):
    Compare dependence info.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-icf-gimple.c

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 4 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Richard,
> thanks, I also think alias trick makes gloal vars safe for merging across
> RESTRICT flags. 
> 
> One however needs to consider merging of items referring restricted vars.
> 
> const restrict int *a=&var;
> const int *b = &var; 
> 
> const int **ptrs1={&a};
> const int **ptrs2=[&b};
> 
> with -fmerge-all-constants we may merge ptrs1 and ptrs2 and, in the late
> compilation, in turn fold expression "ptrs2[0]" into a restricted pointer to
> var?

So we merge a and b with introducing an alias which is why we can
merge ptrs1 and ptrs2, correct?  But still with introducing an
alias.  But folding ptrs1[0] and ptrs2[0] will now return the same
(but random?) value.

Note that it's not folding that can introduce issues but points-to
analysis and what it computes for the globals ptrs1 and ptrs2
and thus for code that reads from them.

We are not really parsing constructors fully in PTA - at least I see

ptrs1 = NONLOCAL
ptrs1.0_2 = ptrs1
_3 = *ptrs1.0_2 
_4 = *_3        

only for

int var;
const int * restrict a=&var;
const int *b = &var;

const int * const *ptrs1={&a};
const int * const *ptrs2={&b};

int main()
{
  return *(ptrs1[0]);
}

IPA PTA does sth funny though:

ptrs2 = NONLOCAL
b = NONLOCAL
var = NONLOCAL
b = &var
ESCAPED = &var
ptrs2 = &b
ESCAPED = &b
ptrs1 = NONLOCAL
a = &GLOBAL_RESTRICT
GLOBAL_RESTRICT = NONLOCAL
ptrs1 = &a
ESCAPED = &a

but obviously we don't seem to merge ptrs1/ptrs2.  But IPA PTA
needs quite some thoughts with respect to aliases I think (and
in other ways as well...).

> If this case is legit, the correct place to match RESTRICT flags is
> compare_cgraph_references. We can also go with your patch that will make A and
> B considered to be different and thus prevent merging PTRS1&PTRS2.

That would certainly be a safe thing to do.

Even with -flto -fmerge-all-constants we don't get ptrs1 and ptrs2
merged it seems (with -fwhole-program we fold stuff too early).

Richard.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Here is summary of my current understanding of remaining issues from my last
> weekend's audit.
> 
> ICF specific:
>  - ipa-icf-gimple.c needs to match dependence analysis
>    Richard has propsed a patch for it, so I hope he will commit it tomorrow.
>  - restrict flag may need to be matched when considering two references
>    to variables being equal.
>    Here I am waiting for Richards comment. I would propose matching restricts
> in compare_cgraph_references same way as we now compare vtables.

Works for me.  Having a testcase that shows the issue would be
nice though (I don't get the variables merged it seems, or somehow
the initializers prevail even on the aliases?)

> non-ICF specific wrong codes
>  - tree-vectorizer is picking up wrong alignment

Fixed.

>  - fold-const.c's operands_equal_p probably needs same treatment for
>    comparing mem-ref as ipa-icf-gimple has.  I think in all cases one can
>    construct testcase where tree-tail-merge would produce same incorrect
>    merging as ipa-icf does.

No, it simply means that you can't use operand_equal_p (value equivalence)
if you want semantic equivalence in a greater scope.  This is why I
asked for the ICF and tail-merging stmt compare code to be unified ...

> stuff that can wait for next stage1
>  - ipa-pure-const is probably wrong to check TYPE_NEEDS_CONSTRUCTION flag
>    (something to fix for next stage1)
>  - expand_builtin_classify_type can probably be dropped, because
> fold_classify_type prevails.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> I tried to construct a testcase for __restrict__ case:
> int var;
> const int *varptr=&var;
> const int *__restrict__ varptr2=&var;
> 
>  int *__restrict__ varptr3 = &var;
>  int *__restrict__ varptr4 = &var;
> 
> int *
> return_valptr(int i)
> {
>   return varptr[i];
> }
> int * __restrict__
> return_valptr2(int i)
> {
>   return varptr2[i];
> }
> int
> testrestrict ()
> {
>   int *ptr = return_valptr (0);
>   *ptr = 0;
>   *varptr3 = 1;
>   return *ptr;
> }
> int
> testrestrict2 ()
> {
>   int *ptr = return_valptr2 (0);
>   *ptr = 0;
>   *varptr3 = 1;
>   return *ptr;
> }
> int
> testrestrict4 ()
> {
>   *varptr4 = 0;
>   *varptr3 = 1;
>   return *varptr4;
> }
> 
> Here I would like restrict2 to return uncondtional 0, because ptr is taken from
> a restrict pointer in a global var.  For whatever reason this optimization is
> not happening (it happens in testrestrict4). So perhaps we are safe to
> completely ignore restircts on vars, because we never get the flag in through
> folding.

We don't get it ever from folding.  Only IPA PTA looks at global 
constructors, local PTA doesn't - but that's a missed optimization
at least for readonly vars.  Can you please open a new bug with the above
testcase?

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #24 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #22)
> On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> > 
> > --- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> > Here is summary of my current understanding of remaining issues from my last
> > weekend's audit.
> > 
> > ICF specific:
> >  - ipa-icf-gimple.c needs to match dependence analysis
> >    Richard has propsed a patch for it, so I hope he will commit it tomorrow.
> >  - restrict flag may need to be matched when considering two references
> >    to variables being equal.
> >    Here I am waiting for Richards comment. I would propose matching restricts
> > in compare_cgraph_references same way as we now compare vtables.
> 
> Works for me.  Having a testcase that shows the issue would be
> nice though (I don't get the variables merged it seems, or somehow
> the initializers prevail even on the aliases?)
> 
> > non-ICF specific wrong codes
> >  - tree-vectorizer is picking up wrong alignment
> 
> Fixed.
> 
> >  - fold-const.c's operands_equal_p probably needs same treatment for
> >    comparing mem-ref as ipa-icf-gimple has.  I think in all cases one can
> >    construct testcase where tree-tail-merge would produce same incorrect
> >    merging as ipa-icf does.
> 
> No, it simply means that you can't use operand_equal_p (value equivalence)
> if you want semantic equivalence in a greater scope.  This is why I
> asked for the ICF and tail-merging stmt compare code to be unified ...

Still on my radar, few months ago, I was able to come up with prototype that
was at least as good as current implementation. It can be adopted for next
release.

> 
> > stuff that can wait for next stage1
> >  - ipa-pure-const is probably wrong to check TYPE_NEEDS_CONSTRUCTION flag
> >    (something to fix for next stage1)
> >  - expand_builtin_classify_type can probably be dropped, because
> > fold_classify_type prevails.
>From gcc-bugs-return-479455-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 05 11:37:10 2015
Return-Path: <gcc-bugs-return-479455-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 96181 invoked by alias); 5 Mar 2015 11:37:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 96145 invoked by uid 48); 5 Mar 2015 11:37:07 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65322] Narrowing conversion
Date: Thu, 05 Mar 2015 11:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65322-4-yY9ACItImd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65322-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65322-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00599.txt.bz2
Content-length: 511

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide322

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Wolfgang Roehrl from comment #3)
> The compiler rejects this program too - is this correct?

Yes. Adding constexpr to the constructor only means that it *can* be used in
constant-expressions, not that it is always a constant-expression, so in the
general case 'b' is still a run-time variable not a constant.

Just use m_counter( b ? 1u : 0u ) or m_counter{ short(b ? 1u : 0u) }

[Bug ipa/65270] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[5 regression] ICF needs to |issues with merging memory
                   |match TYPE attributes on    |accesses from different
                   |memory accesses             |code paths

--- Comment #25 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I think the ICF wrong code mentioned here should be now all fixed.  

I did not manage to create a testcase for RESTRICT flag unification, because
the RESTRICT flag seems to not be taken into an account when the variable is
references thorough pointer to another variable.

I think we do have problem with operand_equal_p being used across different
contexts in several cases (not only in tree-tail-merge). Perhaps for next
stage1 we ought to separate the logic into icf-op class that will have enough
flexibility to do the right thing in all cases? (i.e. have valueize hook that
can be used by ICF to prove equivalences across classes and in addition to
existing operand_equal_p flags it will actually know if it should match memory
attributes because the operands come from different code path/broader context). 

icf-op also should have hash method to produce stable hash so it can be plugged
into icf-gimple (that in turn can be plugged into tree-tail-merge).

[Bug ipa/65270] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #26 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I completely missed the discussion concerning restrict. I opened PR65330 with
that testcase.  We can check in the following way:
Index: ipa-icf.c
===================================================================
--- ipa-icf.c   (revision 221223)
+++ ipa-icf.c   (working copy)
@@ -359,6 +359,13 @@ sem_item::compare_cgraph_references (
     return return_false_with_msg
             ("references to virtual tables can not be merged");

+  if (is_a <varpool_node *> (n1)
+      && POINTER_TYPE_P (TREE_TYPE (n1->decl))
+      && TYPE_RESTRICT (TREE_TYPE (n1->decl))
+        != TYPE_RESTRICT (TREE_TYPE (n2->decl)))
+    return return_false_with_msg
+            ("references have different restirct flags");
+
   if (address && n1->equal_address_to (n2) == 1)
     return true;
   if (!address && n1->semantically_equivalent_p (n2))

but I suppose with strong enough restrict handling, we want to actually walk
the type and match restrict flag in all contained pointers? Shall we track it
in PR65330, too? It is a non-bug until the missed optimization is fixed.

[Bug ipa/65270] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #27 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
here is a variant of orignal testcase for tree-tail-merge

struct a 
{
  int a[100000];
};
typedef struct a misaligned_t __attribute__ ((aligned (8)));
typedef struct a aligned_t __attribute__ ((aligned (32)));

__attribute__ ((used))
__attribute__ ((noinline))
t(void *a, int misaligned, aligned_t *d)
{
  int i,v;
  for (i=0;i<100000;i++)
    {
        if (misaligned)
          v=((misaligned_t *)a)->a[i];
        else
          v=((aligned_t *)a)->a[i];
        d->a[i]+=v;
    }
}
struct b {int v; misaligned_t m;aligned_t aa;} b;
aligned_t d;
main()
{
  t(&b.m, 1, &d);
}

$ ./xgcc -B ./ -O3 t.c -fdump-tree-all-details  
t.c:10:1: warning: return type defaults to �int� [-Wimplicit-int]
 t(void *a, int misaligned, aligned_t *d)
 ^
t.c:24:1: warning: return type defaults to �int� [-Wimplicit-int]
 main()
 ^
$ ./a.out
Segmentation fault

It works (by accident) for GCC 4.7, so it is a regression again...
>From gcc-bugs-return-479514-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 05 20:22:31 2015
Return-Path: <gcc-bugs-return-479514-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25877 invoked by alias); 5 Mar 2015 20:22:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25715 invoked by uid 48); 5 Mar 2015 20:22:27 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65323] -Wzero-as-null-pointer-constant stutters
Date: Thu, 05 Mar 2015 20:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-65323-4-13cchKyKCl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65323-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65323-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00658.txt.bz2
Content-length: 407

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide323

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-05
     Ever confirmed|0                           |1

[Bug ipa/65270] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #28 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
.. and yet another variant, this time folded early. 

struct a 
{
  int a[100000];
};
typedef struct a misaligned_t __attribute__ ((aligned (8)));
typedef struct a aligned_t __attribute__ ((aligned (32)));

__attribute__ ((used))
__attribute__ ((noinline))
t(void *a, int misaligned, aligned_t *d)
{
  int i,v;
  for (i=0;i<100000;i++)
    d->a[i]+=!misaligned? ((aligned_t *)a)->a[i] : ((misaligned_t *)a)->a[i];
}
struct b {int v; misaligned_t m;aligned_t aa;} b;
aligned_t d;
main()
{
  t(&b.m, 1, &d);
}

[Bug ipa/65270] issues with merging memory accesses from different code paths

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
> 
> --- Comment #26 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> I completely missed the discussion concerning restrict. I opened PR65330 with
> that testcase.  We can check in the following way:
> Index: ipa-icf.c
> ===================================================================
> --- ipa-icf.c   (revision 221223)
> +++ ipa-icf.c   (working copy)
> @@ -359,6 +359,13 @@ sem_item::compare_cgraph_references (
>      return return_false_with_msg
>              ("references to virtual tables can not be merged");
> 
> +  if (is_a <varpool_node *> (n1)
> +      && POINTER_TYPE_P (TREE_TYPE (n1->decl))
> +      && TYPE_RESTRICT (TREE_TYPE (n1->decl))
> +        != TYPE_RESTRICT (TREE_TYPE (n2->decl)))
> +    return return_false_with_msg
> +            ("references have different restirct flags");
> +
>    if (address && n1->equal_address_to (n2) == 1)
>      return true;
>    if (!address && n1->semantically_equivalent_p (n2))
> 
> but I suppose with strong enough restrict handling, we want to actually walk
> the type and match restrict flag in all contained pointers? Shall we track it
> in PR65330, too? It is a non-bug until the missed optimization is fixed.

Yes, let's track it there, too.

[Bug ipa/65270] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #30 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, thanks! Any ideas on Comment 26/27 testcases?

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|issues with merging memory  |[5 regression] issues with
                   |accesses from different     |merging memory accesses
                   |code paths                  |from different code paths

--- Comment #31 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Marking it as a regression again because of testcases for folding and
tree-tail-merge in Comment 27 and Comment 28 that passes on older compilers.

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #30)
> OK, thanks! Any ideas on Comment 26/27 testcases?

I have a patch.

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed (again - please open new bugreports for new issues ... the last fix is
eligible for backporting I think).

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Mar  9 13:54:28 2015
New Revision: 221281

URL: https://gcc.gnu.org/viewcvs?rev=221281&root=gcc&view=rev
Log:
2015-03-09  Richard Biener  <rguenther@suse.de>

    PR middle-end/65270
    * tree-core.h (enum operand_equal_flag): Add OEP_ADDRESS_OF.
    * fold-const.c (operand_equal_p): When recursing for ADDR_EXPRs
    operand set OEP_ADDRESS_OF.  Clear it when recursing to non-bases
    of that.  When comparing dereferences compare alignment.
    When comparing MEM_REFs or TARGET_MEM_REFs compare dependence info.

    * gcc.dg/torture/pr65270-1.c: New testcase.
    * gcc.dg/torture/pr65270-2.c: Likewise. 

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr65270-1.c
    trunk/gcc/testsuite/gcc.dg/torture/pr65270-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-core.h

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Mar 12 13:02:42 2015
New Revision: 221386

URL: https://gcc.gnu.org/viewcvs?rev=221386&root=gcc&view=rev
Log:
2015-03-12  Richard Biener  <rguenther@suse.de>

    PR middle-end/65270
    * fold-const.c (operand_equal_p): Fix ordering of resetting
    OEP_ADDRESS_OF and checking for it in the [TARGET_]MEM_REF case.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c