This patch to the Go frontend permits expressions of abstract bool to
remain abstract, rather than forcing them into the named type bool.
The test case for this is https://go.dev/cl/414755.  This fixes
https://go.dev/issue/51475.  Bootstrarpped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
eebc9c8f0b23acddea253eb5a44f59f44f3f466b
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 16d274ce99d..a0e386ab4f6 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-927528cdc112fc51e0d07ee79e7a1254b586eabe
+28fe9fad4acb4e02083faf5503b06e3e6e8eecaf
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index f59f61d19ad..aadca9710e6 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -6829,11 +6829,12 @@ Binary_expression::do_determine_type(const 
Type_context* context)
     {
       if ((tleft->integer_type() != NULL && tright->integer_type() != NULL)
          || (tleft->float_type() != NULL && tright->float_type() != NULL)
-         || (tleft->complex_type() != NULL && tright->complex_type() != NULL))
+         || (tleft->complex_type() != NULL && tright->complex_type() != NULL)
+         || (tleft->is_boolean_type() && tright->is_boolean_type()))
        {
-         // Both sides have an abstract integer, abstract float, or
-         // abstract complex type.  Just let CONTEXT determine
-         // whether they may remain abstract or not.
+         // Both sides have an abstract integer, abstract float,
+         // abstract complex, or abstract boolean type.  Just let
+         // CONTEXT determine whether they may remain abstract or not.
        }
       else if (tleft->complex_type() != NULL)
        subcontext.type = tleft;

Reply via email to