| Message ID | CAEwic4b=mRSJk+boZ42SCMbEi3qqWGtswh5Uaii=UNKbvbSU=A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 01/26/2012 05:44 AM, Kai Tietz wrote: > the following patch fixes a bootstrap issue for libjava (compile of > verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND > lhs side has always a type. This isn't necessarily true, but it has > by default boolean_type_node as type. A perfectly valid assumption. The Java front end must have forgotten to set the type (to at least void_type_node). r~
On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson <rth@redhat.com> wrote: > On 01/26/2012 05:44 AM, Kai Tietz wrote: >> the following patch fixes a bootstrap issue for libjava (compile of >> verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND >> lhs side has always a type. This isn't necessarily true, but it has >> by default boolean_type_node as type. > > A perfectly valid assumption. The Java front end must have forgotten > to set the type (to at least void_type_node). verify.cc is a C++ code so it is the C++ front-end. Thanks, Andrew Pinski
On Wed, Jan 25, 2012 at 10:00 PM, Andrew Pinski <pinskia@gmail.com> wrote: > On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson <rth@redhat.com> wrote: >> On 01/26/2012 05:44 AM, Kai Tietz wrote: >>> the following patch fixes a bootstrap issue for libjava (compile of >>> verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND >>> lhs side has always a type. This isn't necessarily true, but it has >>> by default boolean_type_node as type. >> >> A perfectly valid assumption. The Java front end must have forgotten >> to set the type (to at least void_type_node). > > verify.cc is a C++ code so it is the C++ front-end. Still the assumption is perfectly valid - I suppose you simply got an SSA name that is on the free list here for some reason? Richard. > Thanks, > Andrew Pinski
2012/1/26 Richard Guenther <richard.guenther@gmail.com>: > On Wed, Jan 25, 2012 at 10:00 PM, Andrew Pinski <pinskia@gmail.com> wrote: >> On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson <rth@redhat.com> wrote: >>> On 01/26/2012 05:44 AM, Kai Tietz wrote: >>>> the following patch fixes a bootstrap issue for libjava (compile of >>>> verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND >>>> lhs side has always a type. This isn't necessarily true, but it has >>>> by default boolean_type_node as type. >>> >>> A perfectly valid assumption. The Java front end must have forgotten >>> to set the type (to at least void_type_node). >> >> verify.cc is a C++ code so it is the C++ front-end. > > Still the assumption is perfectly valid - I suppose you simply got an SSA name > that is on the free list here for some reason? > > Richard. Sorry for the noise. I have found the problem. It was self-made. Kai
Index: tree-eh.c =================================================================== --- tree-eh.c (revision 183524) +++ tree-eh.c (working copy) @@ -2583,9 +2583,14 @@ && TREE_CODE_CLASS (code) == tcc_comparison) t = TREE_TYPE (gimple_assign_rhs1 (stmt)); else if (gimple_code (stmt) == GIMPLE_COND) - t = TREE_TYPE (gimple_cond_lhs (stmt)); + { + t = TREE_TYPE (gimple_cond_lhs (stmt)); + if (t == NULL_TREE) + t = boolean_type_node; + } else - t = gimple_expr_type (stmt); + t = gimple_expr_type (stmt); + fp_operation = FLOAT_TYPE_P (t); if (fp_operation) {
Hi, the following patch fixes a bootstrap issue for libjava (compile of verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND lhs side has always a type. This isn't necessarily true, but it has by default boolean_type_node as type. ChangeLog 2012-01-25 Kai Tietz <ktietz@redhat.com> * tree-eh.c (stmt_could_throw_1_p): If type of lhs for a GIMPLE_COND isn't set, use boolean_type_node. Bootstrapped for x86_64-unknown-linux-gnu, and i686-w64-mingw32. Ok for apply? Regards, Kai