[Bug regression/32461] New: [4.3 Regression] internal compiler error: Segmentation fault

[Bug regression/32461] New: [4.3 Regression] internal compiler error: Segmentation fault

[jojelino at gmail dot com]

svn revision 125948
$ gcc -mno-cygwin -O4 bit_allocate.c -save-temps
bit_allocate.c: In function 'a52_bit_allocate':
bit_allocate.c:127: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: [4.3 Regression] internal compiler error: Segmentation
                    fault
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jojelino at gmail dot com


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

[Bug regression/32461] [4.3 Regression] internal compiler error: Segmentation fault

[jojelino at gmail dot com]

------- Comment #1 from jojelino at gmail dot com  2007-06-22 16:01 -------
Created an attachment (id=13762)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13762&action=view)
preprocessed file


-- 


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

[Bug regression/32461] [4.3 Regression] internal compiler error: Segmentation fault

[jojelino at gmail dot com]

------- Comment #2 from jojelino at gmail dot com  2007-06-22 16:06 -------
fails if given -Olevel level>2


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[ubizjak at gmail dot com]

------- Comment #3 from ubizjak at gmail dot com  2007-06-22 18:29 -------
The testcase:

--cut here--
typedef struct
{
  unsigned char exp[256];
}
expbap_t;

void
a52_bit_allocate (expbap_t * expbap)
{
  int i;
  unsigned char *exp;
  exp = expbap->exp;

  int lowcomp;
  do
    {
      if (exp[i + 1] == exp[i] - 2)
        lowcomp = 384;
      else if (lowcomp && (exp[i + 1] > exp[i]))
        lowcomp -= 64;
      i++;
    }
  while ((i < 3) || ((i < 7) && (exp[i] > exp[i - 1])));
}
--cut here--

gcc -O3 -m32:

#0  build_classic_dist_vector_1 (ddr=0xf84eb0, ddr_a=0xf84460, ddr_b=0xf84f50, 
    dist_v=0x2aaaae0aa260, init_b=0x7ffffed24dd7
"\001&#65533;\206&#65533;&#65533;&#65533;*", 
    index_carry=0x7ffffed24dd0) at ../../gcc-svn/trunk/gcc/tree-data-ref.c:2700
#1  0x00000000006c2175 in subscript_dependence_tester (ddr=0xf84eb0, 
    loop_nest=0x2aaaadff86e0) at ../../gcc-svn/trunk/gcc/tree-data-ref.c:2998
#2  0x00000000006c3068 in compute_all_dependences (datarefs=0xf781d0, 
    dependence_relations=0x7ffffed25108, loop_nest=0xf73920, 
    compute_self_and_rr=1 '\001')
    at ../../gcc-svn/trunk/gcc/tree-data-ref.c:3805
#3  0x00000000006c3ebd in compute_data_dependences_for_loop (
    loop=0x2aaaadff86e0, compute_self_and_read_read_dependences=22 '\026', 
    datarefs=0x7ffffed25110, dependence_relations=0x7ffffed25108)
    at ../../gcc-svn/trunk/gcc/tree-data-ref.c:4117
#4  0x0000000000a1d992 in tree_predictive_commoning_loop (loop=0x2aaaadff86e0)
    at ../../gcc-svn/trunk/gcc/tree-predcom.c:2488
#5  0x0000000000a1ee85 in tree_predictive_commoning ()
    at ../../gcc-svn/trunk/gcc/tree-predcom.c:2596
#6  0x0000000000766ee7 in run_tree_predictive_commoning ()
    at ../../gcc-svn/trunk/gcc/tree-ssa-loop.c:184

(gdb) list
2695      for (i = 0; i < DDR_NUM_SUBSCRIPTS (ddr); i++)
2696        {
2697          tree access_fn_a, access_fn_b;
2698          struct subscript *subscript = DDR_SUBSCRIPT (ddr, i);
2699
2700 >>>>     if (chrec_contains_undetermined (SUB_DISTANCE (subscript)))
2701            {
2702              non_affine_dependence_relation (ddr);
2703              return false;
2704            }


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|regression                  |tree-optimization
     Ever Confirmed|0                           |1
   GCC host triplet|                            |i686-pc-linux-gnu
 GCC target triplet|                            |i686-pc-linux-gnu
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-22 18:29:05
               date|                            |
            Summary|[4.3 Regression] internal   |[4.3 Regression]
                   |compiler error: Segmentation|Segmentation fault in
                   |fault                       |build_classic_dist_vector_1(
                   |                            |) at tree-data-ref.c:2700


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #4 from spop at gcc dot gnu dot org  2007-06-23 10:21 -------
The reduced testcase does not seem to work on i686-linux.  However I
can reproduce the ICE with the original bit_allocate.i file.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]



------- Comment #5 from ubizjak at gmail dot com  2007-06-23 10:28 -------
(In reply to comment #4)
> The reduced testcase does not seem to work on i686-linux.  However I
> can reproduce the ICE with the original bit_allocate.i file.

It crashes on x86_64 host when compiling with -O3 -m32. I didn't test it on
i686:

gcc -O3 -m32 pr32461.c
pr32461.c: In function ‘a52_bit_allocate’:
pr32461.c:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #6 from spop at gcc dot gnu dot org  2007-06-23 11:05 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

Okay.

The fail is because one of the folds is not a constant as expected:

MINUS_EXPR
(unsigned int) bndstart_108(D)
(unsigned int) (bndstart_108(D) + 1)
=
0xffffffffffffffff

MINUS_EXPR
(unsigned int) i_434 + 1
(unsigned int) i_434
=
1

but when reversed,

MINUS_EXPR
(unsigned int) i_434
(unsigned int) i_434 + 1
=
~(unsigned int) i_434 + (unsigned int) i_434

the fold result is not an integer_cst, and that lead to the fail.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #7 from spop at gcc dot gnu dot org  2007-06-23 18:10 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

Hi,

In data dependence analysis, when the dependence distance is
lexicographically negative, we recompute the dependence by inverting
the source and the sink memory accesses, and thus we compute the
dependence again but in the opposite direction.  In one way we
compute:

MINUS_EXPR
(unsigned int) i_434 + 1
(unsigned int) i_434
=
1

but when going the other way, backwards, we have to compute:

MINUS_EXPR
(unsigned int) i_434
(unsigned int) i_434 + 1
=
~(unsigned int) i_434 + (unsigned int) i_434

and instead of getting an integer_cst, we get that ugly expression
from fold, the dependence test fails, and everything goes wrong from
that point.

With this patch we get the expected 0xffffffffffffffff for the above
case.  The patch teaches fold how to compute the minus expression for
unsigned int and pointer expressions.

Bootstrapped and tested on i686-linux.  Okay for trunk?

Sebastian


------- Comment #8 from spop at gcc dot gnu dot org  2007-06-23 18:10 -------
Created an attachment (id=13768)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13768&action=view)


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[richard dot guenther at gmail dot com]

------- Comment #9 from richard dot guenther at gmail dot com  2007-06-23 18:36 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/23/07, Sebastian Pop <spop@gcc.gnu.org> wrote:
> Hi,
>
> In data dependence analysis, when the dependence distance is
> lexicographically negative, we recompute the dependence by inverting
> the source and the sink memory accesses, and thus we compute the
> dependence again but in the opposite direction.  In one way we
> compute:
>
> MINUS_EXPR
> (unsigned int) i_434 + 1
> (unsigned int) i_434
> =
> 1
>
> but when going the other way, backwards, we have to compute:
>
> MINUS_EXPR
> (unsigned int) i_434
> (unsigned int) i_434 + 1
> =
> ~(unsigned int) i_434 + (unsigned int) i_434
>
> and instead of getting an integer_cst, we get that ugly expression
> from fold, the dependence test fails, and everything goes wrong from
> that point.
>
> With this patch we get the expected 0xffffffffffffffff for the above
> case.  The patch teaches fold how to compute the minus expression for
> unsigned int and pointer expressions.
>
> Bootstrapped and tested on i686-linux.  Okay for trunk?

First - can you check why the asociate: case in fold_binary does not do
the transformation and maybe fix that instead if possible?

Then there is a ChangeLog missing.  Further...

+         && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0,
+                                        TREE_OPERAND (arg1, 0))))

to avoid creating trees and just throwing them away you should use
operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead.  You
similarly may want to check operand 1 for A - (B + A)?

+         && TYPE_UNSIGNED (type)

you should check TYPE_OVERFLOW_WRAPS (type)  instead.

Thanks,
Richard.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[richard dot guenther at gmail dot com]

------- Comment #10 from richard dot guenther at gmail dot com  2007-06-23 19:24 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/23/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 6/23/07, Sebastian Pop <spop@gcc.gnu.org> wrote:
> > Hi,
> >
> > In data dependence analysis, when the dependence distance is
> > lexicographically negative, we recompute the dependence by inverting
> > the source and the sink memory accesses, and thus we compute the
> > dependence again but in the opposite direction.  In one way we
> > compute:
> >
> > MINUS_EXPR
> > (unsigned int) i_434 + 1
> > (unsigned int) i_434
> > =
> > 1
> >
> > but when going the other way, backwards, we have to compute:
> >
> > MINUS_EXPR
> > (unsigned int) i_434
> > (unsigned int) i_434 + 1
> > =
> > ~(unsigned int) i_434 + (unsigned int) i_434
> >
> > and instead of getting an integer_cst, we get that ugly expression
> > from fold, the dependence test fails, and everything goes wrong from
> > that point.
> >
> > With this patch we get the expected 0xffffffffffffffff for the above
> > case.  The patch teaches fold how to compute the minus expression for
> > unsigned int and pointer expressions.
> >
> > Bootstrapped and tested on i686-linux.  Okay for trunk?
>
> First - can you check why the asociate: case in fold_binary does not do
> the transformation and maybe fix that instead if possible?
>
> Then there is a ChangeLog missing.  Further...
>
> +         && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0,
> +                                        TREE_OPERAND (arg1, 0))))
>
> to avoid creating trees and just throwing them away you should use
> operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead.  You
> similarly may want to check operand 1 for A - (B + A)?
>
> +         && TYPE_UNSIGNED (type)
>
> you should check TYPE_OVERFLOW_WRAPS (type)  instead.

Oh - and there is omit_two_operands which you should use to
omit the two As.  This takes care of side-effects.

Richard.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]



------- Comment #11 from spop at gcc dot gnu dot org  2007-06-24 06:48 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

Hi,

On 6/23/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > First - can you check why the asociate: case in fold_binary does not do
> > the transformation and maybe fix that instead if possible?
> >

The associate case is the last case for MINUS_EXPR, but the case
      /* A - B -> A + (-B) if B is easily negatable.  */
applies, and returns ~(unsigned int) i_434 + (unsigned int) i_434
before going to execute the associate code.

Unfortunately I haven't seen the suggestion of Håkan Hjort to also
implement the fold of ~a + a ==> ~0.  I could add a new patch for this
one too in the next bootstrap if the current patch still has issues.

> > +         && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0,
> > +                                        TREE_OPERAND (arg1, 0))))
> >
> > to avoid creating trees and just throwing them away you should use
> > operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead.

Hmm, this was my first implementation, as I just mimicked the code
just before, that is using operand_equal_p.  However in my case I have
'A' and 'nop(unsigned int, A)' so they are not exactly the same trees,
but the difference is zero.

> > You similarly may want to check operand 1 for A - (B + A)?
> >

yes, okay.

> > +         && TYPE_UNSIGNED (type)
> >
> > you should check TYPE_OVERFLOW_WRAPS (type)  instead.
>
> Oh - and there is omit_two_operands which you should use to
> omit the two As.  This takes care of side-effects.
>

done.

The attached patch bootstrapped and passed test on i686-linux.

Sebastian


------- Comment #12 from spop at gcc dot gnu dot org  2007-06-24 06:48 -------
Created an attachment (id=13770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13770&action=view)


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[sebpop at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]



------- Comment #13 from sebpop at gmail dot com  2007-06-24 07:55 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <spop@gcc.gnu.org> wrote:
> Unfortunately I haven't seen the suggestion of Håkan Hjort to also
> implement the fold of ~a + a ==> ~0.  I could add a new patch for this
> one too in the next bootstrap if the current patch still has issues.
>

I just realized that we already implement this:
          /* ~X + X is -1.  */
          /* X + ~X is -1.  */

But, in our case, when we arrive at this point, it is useless because
it uses operand_equal_p, so the above test fails, and we don't enter
that code:

          /* ~X + X is -1.  */
          if (TREE_CODE (arg0) == BIT_NOT_EXPR
              && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
              && !TYPE_OVERFLOW_TRAPS (type))
            {
              t1 = build_int_cst_type (type, -1);
              return omit_one_operand (type, t1, arg1);
            }

and at that point we have:

(gdb) call debug_tree (arg0)
 <bit_not_expr 0xb7cd67c0
    type <integer_type 0xb7c2c000 unsigned int public unsigned sizetype SI
        size <integer_cst 0xb7c1d658 constant invariant 32>
        unit size <integer_cst 0xb7c1d444 constant invariant 4>
        align 32 symtab 0 alias set -1 canonical type 0xb7c320d8
precision 32 min <integer_cst 0xb7c1d674 0> max <integer_cst
0xb7c1dc08 -1>>

    arg 0 <nop_expr 0xb7cd65a0 type <integer_type 0xb7c2c000 unsigned int>

        arg 0 <ssa_name 0xb7cd230c type <integer_type 0xb7c2c2f4 int>
            volatile visited var <var_decl 0xb7cce000 i> def_stmt
<nop_expr 0xb7cc5940>
            version 4>>>
(gdb) call debug_tree (arg1)
 <ssa_name 0xb7cd230c
    type <integer_type 0xb7c2c2f4 int sizes-gimplified public SI
        size <integer_cst 0xb7c1d658 constant invariant 32>
        unit size <integer_cst 0xb7c1d444 constant invariant 4>
        align 32 symtab 0 alias set 2 canonical type 0xb7c2c2f4
precision 32 min <integer_cst 0xb7c1d604 -2147483648> max <integer_cst
0xb7c1d620 2147483647>
        pointer_to_this <pointer_type 0xb7c32798>>
    volatile visited var <var_decl 0xb7cce000 i> def_stmt <nop_expr 0xb7cc5940>
    version 4>


So this just looks like we want to improve operand_equal_p, and not
touch the folder this time.  Probably we can implement one more flag
for stripping nop conversions of operands.

Sebastian


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[sebpop at gmail dot com]

------- Comment #14 from sebpop at gmail dot com  2007-06-24 10:11 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> So this just looks like we want to improve operand_equal_p, and not
> touch the folder this time.  Probably we can implement one more flag
> for stripping nop conversions of operands.
>

Actually I think that the test in operand_equal_p is too strong for
our case where the expression under the nops is just an SSA_NAME.

Would a patch like the following one be acceptable?  I've put this
patch to bootstrap and test with --enable-checking=yes,fold,rtl.

Sebastian


------- Comment #15 from sebpop at gmail dot com  2007-06-24 10:11 -------
Created an attachment (id=13774)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13774&action=view)


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[ebotcazou at libertysurf dot fr]

------- Comment #16 from ebotcazou at libertysurf dot fr  2007-06-24 10:26 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

> and at that point we have:
>
> (gdb) call debug_tree (arg0)
>  <bit_not_expr 0xb7cd67c0
>     type <integer_type 0xb7c2c000 unsigned int public unsigned sizetype SI
>         size <integer_cst 0xb7c1d658 constant invariant 32>
>         unit size <integer_cst 0xb7c1d444 constant invariant 4>
>         align 32 symtab 0 alias set -1 canonical type 0xb7c320d8
> precision 32 min <integer_cst 0xb7c1d674 0> max <integer_cst
> 0xb7c1dc08 -1>>
>
>     arg 0 <nop_expr 0xb7cd65a0 type <integer_type 0xb7c2c000 unsigned int>
>
>         arg 0 <ssa_name 0xb7cd230c type <integer_type 0xb7c2c2f4 int>
>             volatile visited var <var_decl 0xb7cce000 i> def_stmt
> <nop_expr 0xb7cc5940>
>             version 4>>>
> (gdb) call debug_tree (arg1)
>  <ssa_name 0xb7cd230c
>     type <integer_type 0xb7c2c2f4 int sizes-gimplified public SI
>         size <integer_cst 0xb7c1d658 constant invariant 32>
>         unit size <integer_cst 0xb7c1d444 constant invariant 4>
>         align 32 symtab 0 alias set 2 canonical type 0xb7c2c2f4
> precision 32 min <integer_cst 0xb7c1d604 -2147483648> max <integer_cst
> 0xb7c1d620 2147483647>
>         pointer_to_this <pointer_type 0xb7c32798>>
>     volatile visited var <var_decl 0xb7cce000 i> def_stmt <nop_expr
> 0xb7cc5940> version 4>

Why are the operands of different type at that point?


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[pinskia at gmail dot com]

------- Comment #17 from pinskia at gmail dot com  2007-06-24 10:27 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> > So this just looks like we want to improve operand_equal_p, and not
> > touch the folder this time.  Probably we can implement one more flag
> > for stripping nop conversions of operands.
> >
>
> Actually I think that the test in operand_equal_p is too strong for
> our case where the expression under the nops is just an SSA_NAME.
>
> Would a patch like the following one be acceptable?  I've put this
> patch to bootstrap and test with --enable-checking=yes,fold,rtl.

I think you just made oep_can_strip_nops too lose. I think you just
need to strip the NOPs off the call to operand_equal_p when doing a +
~a (and ~a + a) folding.  Or maybe use op1/op0 instead.  I don't think
it is safe to strip NOPs even for SSA_NAMES in operand_equal_p.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[pinskia at gmail dot com]

------- Comment #18 from pinskia at gmail dot com  2007-06-24 10:33 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> Why are the operands of different type at that point?

Because there is a STRIP_NOPS in fold_binary and then we look at
BIT_NOT_EXPR's operand which is a NOP_EXPR.  Maybe we should fold
~(int)unsigned_var into (int)~unsigned_var and that would fix the
issue all the time.

As an aside note, I see we might have a type issue with BIT_NOT_EXPR:

      else if (TREE_CODE (arg0) == BIT_NOT_EXPR)
        return TREE_OPERAND (arg0, 0);

if we have ~(int)~unsigned_int, we will get the incorrect type returned.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[ebotcazou at libertysurf dot fr]

------- Comment #19 from ebotcazou at libertysurf dot fr  2007-06-24 10:45 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

> Because there is a STRIP_NOPS in fold_binary and then we look at
> BIT_NOT_EXPR's operand which is a NOP_EXPR.

Ah, yes, thanks.

> Maybe we should fold ~(int)unsigned_var into (int)~unsigned_var and that
> would fix the issue all the time.

What about stripping the NOPs within BIT_NOT_EXPR's operand too before 
invoking operand_equal_p on it?


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[richard dot guenther at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]



------- Comment #20 from richard dot guenther at gmail dot com  2007-06-24 11:40 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 6/24/07, Sebastian Pop <spop@gcc.gnu.org> wrote:
> > Unfortunately I haven't seen the suggestion of Håkan Hjort to also
> > implement the fold of ~a + a ==> ~0.  I could add a new patch for this
> > one too in the next bootstrap if the current patch still has issues.
> >
>
> I just realized that we already implement this:
>           /* ~X + X is -1.  */
>           /* X + ~X is -1.  */
>
> But, in our case, when we arrive at this point, it is useless because
> it uses operand_equal_p, so the above test fails, and we don't enter
> that code:
>
>           /* ~X + X is -1.  */
>           if (TREE_CODE (arg0) == BIT_NOT_EXPR
>               && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
>               && !TYPE_OVERFLOW_TRAPS (type))
>             {
>               t1 = build_int_cst_type (type, -1);
>               return omit_one_operand (type, t1, arg1);
>             }

If you use TREE_OPERAND (op0, 0), op1 instead it should work.  The
problem seems to be that arg0/arg1 have all NOPs stripped, including
those changing the sign.  So we get to compare a and (unsigned)a,
which are obviously not the same.

It looks like most of the users of the arg variants are suspicious in this
regard...

Richard.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[sebpop at gmail dot com]

------- Comment #21 from sebpop at gmail dot com  2007-06-24 12:50 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> If you use TREE_OPERAND (op0, 0), op1 instead it should work.  The
> problem seems to be that arg0/arg1 have all NOPs stripped, including
> those changing the sign.  So we get to compare a and (unsigned)a,
> which are obviously not the same.
>

Right.
The attached patch solves the problem.

> It looks like most of the users of the arg variants are suspicious in this
> regard...
>

So if I'm correctly understanding, you suppose that there are also
other cases in which fold fails just because it uses arg instead of op?

Thanks,
Sebastian


------- Comment #22 from sebpop at gmail dot com  2007-06-24 12:50 -------
Created an attachment (id=13778)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13778&action=view)


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[richard dot guenther at gmail dot com]

------- Comment #23 from richard dot guenther at gmail dot com  2007-06-24 12:59 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 6/24/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > If you use TREE_OPERAND (op0, 0), op1 instead it should work.  The
> > problem seems to be that arg0/arg1 have all NOPs stripped, including
> > those changing the sign.  So we get to compare a and (unsigned)a,
> > which are obviously not the same.
> >
>
> Right.
> The attached patch solves the problem.
>
> > It looks like most of the users of the arg variants are suspicious in this
> > regard...
> >
>
> So if I'm correctly understanding, you suppose that there are also
> other cases in which fold fails just because it uses arg instead of op?

quite possibly.  The patch is ok if it bootstraps & tests and you change

          /* X + ~X is -1.  */
          if (TREE_CODE (arg1) == BIT_NOT_EXPR
-             && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0)
+             && operand_equal_p (op0, TREE_OPERAND (op1, 0), 0)
              && !TYPE_OVERFLOW_TRAPS (type))

to use op1 to check against BIT_NOT_EXPR.  An alternative is to use

          if (TREE_CODE (arg1) == BIT_NOT_EXPR
              && !TYPE_OVERFLOW_TRAPS (type))
             {
                tem = TREE_OPERAND (arg1, 0);
                STRIP_NOPS (tem);
                if (operand_equal_p (arg0, tem, 0))
 ...

which would be even better and shouldn't cause other missed
optimizations.

Thanks,
Richard.

> Thanks,
> Sebastian
>
>


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[rask at sygehus dot dk]

------- Comment #24 from rask at sygehus dot dk  2007-06-24 13:04 -------
Subject: Re:  [4.3 Regression] Segmentation
        fault in build_classic_dist_vector_1()@tree-data-ref.c:2700

On Sun, Jun 24, 2007 at 02:50:37PM +0200, Sebastian Pop wrote:

> 2007-06-24  Sebastian Pop  <sebpop@gmail.com>
> 
> 	* fold-const.c (fold_binary): Use op{0,1} instead of arg{0,1} as
> 	arguments to operand_equal_p.
> 	* testsuite/gcc.dg/tree-ssa/pr32461-1.c: New.
> 	* testsuite/gcc.dg/tree-ssa/pr32461-2.c: New.

   This time, you forgot the line with the PR numer:
        PR middle-end/32461


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[schwab at suse dot de]

------- Comment #25 from schwab at suse dot de  2007-06-24 13:34 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

"Richard Guenther" <richard.guenther@gmail.com> writes:

> quite possibly.  The patch is ok if it bootstraps & tests and you change
>
>          /* X + ~X is -1.  */
>          if (TREE_CODE (arg1) == BIT_NOT_EXPR
> -             && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0)
> +             && operand_equal_p (op0, TREE_OPERAND (op1, 0), 0)

That won't work if op1 != arg1, ie. there are NOPs around BIT_NOT_EXPR.

Andreas.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[sebpop at gmail dot com]

------- Comment #26 from sebpop at gmail dot com  2007-06-24 13:38 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Richard Guenther <richard.guenther@gmail.com> wrote:
>  An alternative is to use
>
>           if (TREE_CODE (arg1) == BIT_NOT_EXPR
>               && !TYPE_OVERFLOW_TRAPS (type))
>              {
>                 tem = TREE_OPERAND (arg1, 0);
>                 STRIP_NOPS (tem);
>                 if (operand_equal_p (arg0, tem, 0))
>  ...
>
> which would be even better and shouldn't cause other missed
> optimizations.
>

Okay, attached is the patch that implements this.
I'm bootstrapping and testing it on i686-linux.

Sebastian


------- Comment #27 from sebpop at gmail dot com  2007-06-24 13:38 -------
Created an attachment (id=13779)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13779&action=view)


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[sebpop at gmail dot com]

------- Comment #28 from sebpop at gmail dot com  2007-06-24 19:19 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 6/24/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> >  An alternative is to use
> >
> >           if (TREE_CODE (arg1) == BIT_NOT_EXPR
> >               && !TYPE_OVERFLOW_TRAPS (type))
> >              {
> >                 tem = TREE_OPERAND (arg1, 0);
> >                 STRIP_NOPS (tem);
> >                 if (operand_equal_p (arg0, tem, 0))
> >  ...
> >
> > which would be even better and shouldn't cause other missed
> > optimizations.
> >
>
> Okay, attached is the patch that implements this.
> I'm bootstrapping and testing it on i686-linux.
>

Passed bootstrap with --enable-checking=yes,fold,rtl
and no new regressions in the testsuite.  Okay for trunk?

> Sebastian
>
>


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[richard dot guenther at gmail dot com]

------- Comment #29 from richard dot guenther at gmail dot com  2007-06-24 19:53 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 6/24/07, Sebastian Pop <sebpop@gmail.com> wrote:
> > On 6/24/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > >  An alternative is to use
> > >
> > >           if (TREE_CODE (arg1) == BIT_NOT_EXPR
> > >               && !TYPE_OVERFLOW_TRAPS (type))
> > >              {
> > >                 tem = TREE_OPERAND (arg1, 0);
> > >                 STRIP_NOPS (tem);
> > >                 if (operand_equal_p (arg0, tem, 0))
> > >  ...
> > >
> > > which would be even better and shouldn't cause other missed
> > > optimizations.
> > >
> >
> > Okay, attached is the patch that implements this.
> > I'm bootstrapping and testing it on i686-linux.
> >
>
> Passed bootstrap with --enable-checking=yes,fold,rtl
> and no new regressions in the testsuite.  Okay for trunk?

Yes, this is ok.

Thanks,
Richard.


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #30 from spop at gcc dot gnu dot org  2007-06-24 20:59 -------
Subject: Bug 32461

Author: spop
Date: Sun Jun 24 20:59:02 2007
New Revision: 125988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125988
Log:
        PR middle-end/32461
        * fold-const.c (fold_binary): Strip nops of operand 0
        of BIT_NOT_EXPR before calling operand_equal_p.
        * testsuite/gcc.dg/tree-ssa/pr32461-1.c: New.
        * testsuite/gcc.dg/tree-ssa/pr32461-2.c: New.


Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32461-1.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32461-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #31 from spop at gcc dot gnu dot org  2007-06-24 21:00 -------
Fixed.


-- 

spop at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[spop at gcc dot gnu dot org]

------- Comment #32 from spop at gcc dot gnu dot org  2007-06-24 21:05 -------
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

I forgot to mention: I tested this patch only on i686-linux.
Can somebody give it a test on amd64 see if it also passes?
I've committed also the testcase that was failing for amd64
as testsuite/gcc.dg/tree-ssa/pr32461-2.c, so this should fail
if it was not the same bug that I've fixed, but there are chances
that it's the exact same code that fails for the -2.c

Sebastian


-- 


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