The Go frontend was inconsistent in determining whether a struct could
use memcmp for the == operator. This could cause one package to decide
that it could use == and a package importing that one to determine that
it could not. The effect was an undefined symbol at link time. This
patch fixes the problem. I've added a test case (bug479) to the master
testsuite, which will be brought over to the gccgo testsuite in due
course. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r 2b23d9831cf7 go/expressions.cc
--- a/go/expressions.cc Wed Sep 18 16:26:07 2013 -0700
+++ b/go/expressions.cc Thu Sep 19 10:28:24 2013 -0700
@@ -7752,8 +7752,6 @@
return false;
if (arg_type->is_abstract())
return false;
- if (arg_type->named_type() != NULL)
- arg_type->named_type()->convert(this->gogo_);
unsigned int ret;
if (this->code_ == BUILTIN_SIZEOF)
diff -r 2b23d9831cf7 go/types.cc
--- a/go/types.cc Wed Sep 18 16:26:07 2013 -0700
+++ b/go/types.cc Thu Sep 19 10:28:24 2013 -0700
@@ -2288,9 +2288,7 @@
}
case TYPE_NAMED:
- // Begin converting this type to the backend representation.
- // This will create a placeholder if necessary.
- this->get_backend(gogo);
+ this->named_type()->convert(gogo);
return this->named_type()->is_named_backend_type_size_known();
case TYPE_FORWARD:
