[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-05-27
          Component|rtl-optimization            |tree-optimization
      Known to work|                            |4.6.4
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Target Milestone|---                         |4.7.4
            Summary|hang on volatile int array  |[4.7/4.8/4.9 Regression]
                   |                            |hang on volatile int array
     Ever confirmed|0                           |1

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

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The existing support for comparing addresses in operand_equal_p cannot handle
this as the volatile array is local.

It seems to me that there is no good reason to ever treat addresses of
TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
on offset determining pieces (though that would rely on gimplification
for COMPONENT_REFs?).

I wonder if this is the right time to introduce gimple_op_equal_p (),
wrapping operand_equal_p but handling a few cases less conservative...

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

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

Like the attached.

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> It seems to me that there is no good reason to ever treat addresses of
> TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
> on offset determining pieces (though that would rely on gimplification
> for COMPONENT_REFs?).

Yes, I agree that the handling of addresses looks overly conservative.

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 27 May 2013, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57417
> 
> --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > It seems to me that there is no good reason to ever treat addresses of
> > TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
> > on offset determining pieces (though that would rely on gimplification
> > for COMPONENT_REFs?).
> 
> Yes, I agree that the handling of addresses looks overly conservative.

I suppose TREE_SIDE_EFFECTS matter on the offset expression of
a get_inner_reference call on op0 of the ADDR_EXPR.  For Ada that
would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET 
(field), exp) for example - or do we somehow guarantee that the
offset expressions that do not appear in indexes like operand 1 of
ARRAY_REFs do not contain side-effects?

[Bug tree-optimization/57417] [4.7/4.8 Regression] hang on volatile int array

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I suppose TREE_SIDE_EFFECTS matter on the offset expression of
> a get_inner_reference call on op0 of the ADDR_EXPR.  For Ada that
> would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET 
> (field), exp) for example - or do we somehow guarantee that the
> offset expressions that do not appear in indexes like operand 1 of
> ARRAY_REFs do not contain side-effects?

No, we cannot guarantee that.  But AFAICS operand_equal_p rejects two
ADDR_EXPRs of the same expression when !OEP_ONLY_CONST only because it has
TREE_SIDE_EFFECTS and I don't see why, IOW my understanding is that it should
be possible to add a OEP_ADDRESS_OF flag when !OEP_ONLY_CONST and use it to be
less conservative.

[Bug tree-optimization/57417] [4.7/4.8 Regression] hang on volatile int array

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Aug 29 13:14:59 2013
New Revision: 202074

URL: http://gcc.gnu.org/viewcvs?rev=202074&root=gcc&view=rev
Log:
    Backported from mainline
    2013-07-22  Georg-Johann Lay  <avr@gjlay.de>

    PR testsuite/52641
    * gcc.dg/torture/pr57381.c: Add dg-require-effective-target int32plus.

    2013-05-27  Richard Biener  <rguenther@suse.de>

    PR middle-end/57381
    PR tree-optimization/57417
    * tree-ssa-sccvn.c (vn_reference_fold_indirect): Fix test
    for unchanged base.
    (set_ssa_val_to): Compare addresses using
    get_addr_base_and_unit_offset.

    PR tree-optimization/57417
    * gcc.dg/torture/pr57417.c: New testcase.

    2013-05-23  Richard Biener  <rguenther@suse.de>

    PR middle-end/57381
    * gcc.dg/torture/pr57381.c: New testcase.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57381.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57417.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/57417] [4.7 Regression] hang on volatile int array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[4.7/4.8 Regression] hang   |[4.7 Regression] hang on
                   |on volatile int array       |volatile int array

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 4.8.2+.

[Bug tree-optimization/57417] [4.7 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue May  6 14:22:41 2014
New Revision: 210110

URL: http://gcc.gnu.org/viewcvs?rev=210110&root=gcc&view=rev
Log:
2014-05-06  Richard Biener  <rguenther@suse.de>

    Backport from mainline
    2013-05-27  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/57417
    * tree-ssa-sccvn.c (set_ssa_val_to): Compare addresses using
    get_addr_base_and_unit_offset.

    * gcc.dg/torture/pr57417.c: New testcase.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57417.c
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/tree-ssa-sccvn.c