Message ID | BANLkTimA=+9R3_A1scbpY+5qX6QHy6ouRQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
2011/5/18 Kai Tietz <ktietz70@googlemail.com>: > Hello > > As follow-up for logical to binary transition > > 2011-05-18 Kai Tietz <ktietz@redhat.com> > > * tree-cfg.c (verify_gimple_assign_binary): Barf on > TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR. > (gimplify_expr): Boolify TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, > TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR. Additionally > move TRUTH_AND|OR|XOR_EXPR to its binary form. > > Boostrapped for x86_64-pc-linux-gnu and regression tested for ada, > fortran, g++, and c. Ok for apply? Additional bootstrapped and regression tested for java, obj-c, and obj-c++. Regression tested alos libstdc++ and libjava. No regressions. Regards, Kai
On Wed, May 18, 2011 at 8:30 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > 2011/5/18 Kai Tietz <ktietz70@googlemail.com>: >> Hello >> >> As follow-up for logical to binary transition >> >> 2011-05-18 Kai Tietz <ktietz@redhat.com> >> >> * tree-cfg.c (verify_gimple_assign_binary): Barf on >> TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR. >> (gimplify_expr): Boolify TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, >> TRUTH_AND_EXPR, TRUTH_OR_EXPR, and TRUTH_XOR_EXPR. Additionally >> move TRUTH_AND|OR|XOR_EXPR to its binary form. >> >> Boostrapped for x86_64-pc-linux-gnu and regression tested for ada, >> fortran, g++, and c. Ok for apply? > > Additional bootstrapped and regression tested for java, obj-c, and > obj-c++. Regression tested alos libstdc++ and libjava. No regressions. Please put a comment before + + switch (TREE_CODE (*expr_p)) + { + case TRUTH_AND_EXPR: + TREE_SET_CODE (*expr_p, BIT_AND_EXPR); + break; + case TRUTH_OR_EXPR: + TREE_SET_CODE (*expr_p, BIT_IOR_EXPR); + break; + case TRUTH_XOR_EXPR: + TREE_SET_CODE (*expr_p, BIT_XOR_EXPR); + break; + default: + break; + } like /* With two-valued operand types binary truth expressions are semantically equivalent to bitwise binary expressions. Canonicalize them to the bitwise variant. */ Eric, how will this interact with Ada boolean types with 8 bit precision and those "invalid" values - will invalid values ever enter into expressions or are they checked before? Can you think of something that would break with s/TRUTH_*_EXPR/BIT_*_EXPR/ for Ada? Thanks, Richard. > Regards, > Kai >
> Eric, how will this interact with Ada boolean types with 8 bit precision > and those "invalid" values - will invalid values ever enter into > expressions or are they checked before? IIUC the Ada semantics is that they must be checked prior to being used. Once they are used, they are "recycled" into valid values. So the issue boils down to how the check is implemented and it doesn't use TRUTH_(AND|OR|XOR) at all. > Can you think of something that would break with s/TRUTH_*_EXPR/BIT_*_EXPR/ > for Ada? No, not at the moment. Thanks for asking in any case.
On Thu, May 19, 2011 at 12:45 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> Eric, how will this interact with Ada boolean types with 8 bit precision >> and those "invalid" values - will invalid values ever enter into >> expressions or are they checked before? > > IIUC the Ada semantics is that they must be checked prior to being used. Once > they are used, they are "recycled" into valid values. So the issue boils down > to how the check is implemented and it doesn't use TRUTH_(AND|OR|XOR) at all. > >> Can you think of something that would break with s/TRUTH_*_EXPR/BIT_*_EXPR/ >> for Ada? > > No, not at the moment. Thanks for asking in any case. Kai, the patch is ok then with the comment added. Thanks, Richard. > -- > Eric Botcazou >
2011/5/19 Richard Guenther <richard.guenther@gmail.com>: > On Thu, May 19, 2011 at 12:45 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: >>> Eric, how will this interact with Ada boolean types with 8 bit precision >>> and those "invalid" values - will invalid values ever enter into >>> expressions or are they checked before? >> >> IIUC the Ada semantics is that they must be checked prior to being used. Once >> they are used, they are "recycled" into valid values. So the issue boils down >> to how the check is implemented and it doesn't use TRUTH_(AND|OR|XOR) at all. >> >>> Can you think of something that would break with s/TRUTH_*_EXPR/BIT_*_EXPR/ >>> for Ada? >> >> No, not at the moment. Thanks for asking in any case. > > Kai, the patch is ok then with the comment added. > > Thanks, > Richard. > >> -- >> Eric Botcazou >> Committed at revision 173903 with suggested comment. Regards, Kai
Index: gcc/gcc/gimplify.c =================================================================== --- gcc.orig/gcc/gimplify.c 2011-05-13 13:15:01.000000000 +0200 +++ gcc/gcc/gimplify.c 2011-05-18 14:03:31.730740200 +0200 @@ -7210,7 +7210,21 @@ gimplify_expr (tree *expr_p, gimple_seq break; } } - + + switch (TREE_CODE (*expr_p)) + { + case TRUTH_AND_EXPR: + TREE_SET_CODE (*expr_p, BIT_AND_EXPR); + break; + case TRUTH_OR_EXPR: + TREE_SET_CODE (*expr_p, BIT_IOR_EXPR); + break; + case TRUTH_XOR_EXPR: + TREE_SET_CODE (*expr_p, BIT_XOR_EXPR); + break; + default: + break; + } /* Classified as tcc_expression. */ goto expr_2; Index: gcc/gcc/tree-cfg.c =================================================================== --- gcc.orig/gcc/tree-cfg.c 2011-05-18 14:01:18.000000000 +0200 +++ gcc/gcc/tree-cfg.c 2011-05-18 14:05:06.512276000 +0200 @@ -3555,29 +3555,11 @@ do_pointer_plus_expr_check: case TRUTH_ANDIF_EXPR: case TRUTH_ORIF_EXPR: - gcc_unreachable (); - case TRUTH_AND_EXPR: case TRUTH_OR_EXPR: case TRUTH_XOR_EXPR: - { - /* We require two-valued operand types. */ - if (!(TREE_CODE (rhs1_type) == BOOLEAN_TYPE - || (INTEGRAL_TYPE_P (rhs1_type) - && TYPE_PRECISION (rhs1_type) == 1)) - || !(TREE_CODE (rhs2_type) == BOOLEAN_TYPE - || (INTEGRAL_TYPE_P (rhs2_type) - && TYPE_PRECISION (rhs2_type) == 1))) - { - error ("type mismatch in binary truth expression"); - debug_generic_expr (lhs_type); - debug_generic_expr (rhs1_type); - debug_generic_expr (rhs2_type); - return true; - } - break; - } + gcc_unreachable (); case LT_EXPR: case LE_EXPR: