[Bug middle-end/49938] New: [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[Bug middle-end/49938] New: [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[markus at trippelsdorf dot de]

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

           Summary: [4.7 regression] ICE in interpret_loop_phi, at
                    tree-scalar-evolution.c:1645
           Product: gcc
           Version: 4.7.0
               URL:
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: markus@trippelsdorf.de


This ICE happened when building chromium. 
Testcase reduced with multidelta:

 % cat test.cpp
#include <vector>
#include <unistd.h>
typedef unsigned short uint16;

namespace base {
        class StringPiece
        {
                public:    typedef size_t size_type;
                           size_type size() const { return length_; } size_type
length_;
        };
}

namespace net {
        class DNSSECKeySet
        {
                bool CheckSignature (const base::StringPiece& name, const
                                base::StringPiece& zone, const
                                base::StringPiece& signature, uint16 rrtype,
                                const std::vector<base::StringPiece>& rrdatas);
        };
}

template <class C> class scoped_array
        {
        public: typedef C element_type;
        explicit scoped_array(C* p = __null):array_(p) {}
        private:   C* array_;
        };

namespace net {
        bool DNSSECKeySet::CheckSignature (const base::StringPiece& name,
        const base::StringPiece& zone, const base::StringPiece& signature,
        uint16 rrtype, const std::vector<base::StringPiece>& rrdatas)
        {
        unsigned signed_data_len = 0;
        for (std::vector<base::StringPiece>::const_iterator i =
rrdatas.begin();
                        i != rrdatas.end(); i++) {
                signed_data_len += 2;
                signed_data_len += i->size();
        }
        scoped_array<unsigned char> signed_data(new unsigned
char[signed_data_len]);
        }
}

% g++ -O test.cpp
test.cpp: In member function ‘bool net::DNSSECKeySet::CheckSignature(const
base::StringPiece&, const base::StringPiece&, const base::StringPiece&, uint16,
const std::vector<base::StringPiece>&)’:
test.cpp:31:7: internal compiler error: in interpret_loop_phi, at
tree-scalar-evolution.c:1645
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

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

--- Comment #1 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-08-02 03:34:30 UTC ---
git bisect points to revision 176072:

3115bda06f241a032e3e5dca50556203a98767a0 is the first bad commit
commit 3115bda06f241a032e3e5dca50556203a98767a0
Author: jason <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sat Jul 9 03:33:54 2011 +0000

        PR c++/45437
    gcc/
        * gimplify.c (goa_stabilize_expr): Handle RHS preevaluation in
        compound assignment.
    gcc/c-family/
        * c-omp.c (check_omp_for_incr_expr): Handle preevaluation.
    gcc/cp/
        * typeck.c (cp_build_modify_expr): Preevaluate RHS.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@176072
138bc75d-0d04-0410-961f-82ee72b054a4

Reverting the commit above "fixes" the problem.

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.08.02 09:46:57
                 CC|                            |spop at gcc dot gnu.org
          Component|c++                         |middle-end
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-02 09:46:57 UTC ---
Confirmed.

#2  0x0000000000ecb2b8 in interpret_loop_phi (loop=0x2aaaad43ca18, 
    loop_phi_node=0x2aaaad44f400)
    at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1645
1645          gcc_assert (TREE_CODE (new_init) != POLYNOMIAL_CHREC);
(gdb) call debug_generic_expr (new_init)
{0, +, 2}_1
(gdb) call debug_generic_expr (res)
(unsigned int) {(size_type) {0, +, 2}_1, +, D.8756_24}_1

I'm not sure why the assert should be valid here.  {0, +, 2}_1 is
unsigned int, folding correctly sees that first widening unsigned int
to sizetype and then truncating back is useless.

What's the problem with dealing with a POLYNOMIAL_CHREC here?  Why
not simply return chrec_dont_know instead of asserting?

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[sebpop at gmail dot com]

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

--- Comment #3 from sebpop at gmail dot com <sebpop at gmail dot com> 2011-08-02 15:02:30 UTC ---
On Tue, Aug 2, 2011 at 04:49, rguenth at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> What's the problem with dealing with a POLYNOMIAL_CHREC here?  Why
> not simply return chrec_dont_know instead of asserting?

That's a reasonable fix.

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-03 08:42:25 UTC ---
Mine then.

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-03 11:09:39 UTC ---
Author: rguenth
Date: Wed Aug  3 11:09:35 2011
New Revision: 177267

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177267
Log:
2011-08-03  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/49938
    * tree-scalar-evolution.c (interpret_loop_phi): Gracefully
    deal with a POLYNOMIAL_CHREC.

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

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr49938.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-scalar-evolution.c

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-03 11:10:34 UTC ---
Fixed.