bug296.go is failing on a checkout from today. The caller is putting the 9th argument in r1+32 instead of r1+96 where we expect: 0x000000001000195c <+140>: std r27,32(r1) <----- 0x0000000010001960 <+144>: li r10,22 0x0000000010001964 <+148>: std r2,24(r1) 0x0000000010001968 <+152>: addi r31,r31,1 0x000000001000196c <+156>: mtctr r11 The failure bisected to: 2c809f8f2584460a5207662cc8e064486cb0ec30 (Sync to current external repository)
I just realised I gave a git commit id from the mirror. The ChangeLog entry is: +2014-04-14 Chris Manghane <cmang@google.com> + + * go-gcc.cc: Include "convert.h". + (Gcc_backend::string_constant_expression): New function. + (Gcc_backend::real_part_expression): Likewise. + (Gcc_backend::imag_part_expression): Likewise. + (Gcc_backend::complex_expression): Likewise. + (Gcc_backend::constructor_expression): Likewise. + (Gcc_backend::array_constructor_expression): Likewise. + (Gcc_backend::pointer_offset_expression): Likewise. + (Gcc_backend::array_index_expression): Likewise. + (Gcc_backend::call_expression): Likewise. + (Gcc_backend::exception_handler_statement): Likewise. + (Gcc_backend::function_defer_statement): Likewise. + (Gcc_backend::function_set_parameters): Likewise. + (Gcc_backend::function_set_body): Likewise. + (Gcc_backend::convert_expression): Handle various type + conversions.
Confirmed. This commit seems to have reverted the effects of the bug fix here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02994.html
Created attachment 32626 [details] possible patch
I don't have a PPC system. Can you see if the attached patch to gcc/go/gofrontend/expressions.cc fixes the problem?
(In reply to Ian Lance Taylor from comment #4) > I don't have a PPC system. Can you see if the attached patch to > gcc/go/gofrontend/expressions.cc fixes the problem? Yes, this makes bug296.go PASS again on powerpc64le. Thanks for the quick fix!
Author: ian Date: Thu Apr 17 19:27:22 2014 New Revision: 209494 URL: http://gcc.gnu.org/viewcvs?rev=209494&root=gcc&view=rev Log: PR go/60870 compiler: Don't convert function type for an interface method. For an interface method the function type is the type without the receiver, which is wrong since we are passing a receiver. The interface method will always have the correct type in this case, so no type conversion is necessary. Also don't do the type conversion when calling a named function, since in that case the type is also always correct. The type can be wrong, and the conversion required, when the function type refers to itself recursively. Modified: trunk/gcc/go/gofrontend/expressions.cc
Fixed.