[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- I verified that tests now passed on 32-bit SPARC.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #5 from Eric Botcazou ---
> What is different about 32-bit SPARC is not that it treats pointers and
> integers differently, but that
>
> struct { void *p; }
>
> and
>
> void *p;
>
> are passed as arguments in two different ways. The former is passed by
> invisible reference and the latter is passed directly. On many platforms
> they are passed as arguments in exactly the same way.
Thanks. I'm a little skeptical about the "many" here, although that's probably
true for modern architectures. In any case, assuming that scalar and structure
types are passed the same way is clearly an unwarranted assumption overall.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #4 from Ian Lance Taylor ---
What is different about 32-bit SPARC is not that it treats pointers and
integers differently, but that
struct { void *p; }
and
void *p;
are passed as arguments in two different ways. The former is passed by
invisible reference and the latter is passed directly. On many platforms they
are passed as arguments in exactly the same way.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 --- Comment #3 from Eric Botcazou --- It's not obvious to me why this would have anything to do with the calling convention on SPARC 32-bit, which is very reasonable. For example, it's not like M68k where pointers and integers are passed differently.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- I have them too.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri May 17 05:49:22 2019 New Revision: 271310 URL: https://gcc.gnu.org/viewcvs?rev=271310=gcc=rev Log: PR go/90482 compiler: make value method of direct interface type takes pointer Currently, a value method of a direct interface type takes the value of the receiver, which is pointer shaped, as the first parameter. When this method is called through interface, we actually pass the interface data as a pointer. On most platforms this is ok, as the underlying calling convention is the same, except that on SPARC32, the calling convention is actually different. This CL changes the method function actually takes a pointer. The function will convert the pointer to the pointer-shaped receiver type (a no-op conversion from machine code's aspect). For a direct call, in the caller we convert the receiver to a pointer (also no-op conversion) before invoking the method. For an interface call, we pass the pointer as before. This way, it is consistent that we always pass a pointer. Hopefully this fixes SPARC32 build and https://gcc.gnu.org/PR90482. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/177758 Modified: trunk/gcc/go/gofrontend/MERGE trunk/gcc/go/gofrontend/expressions.cc trunk/gcc/go/gofrontend/expressions.h trunk/gcc/go/gofrontend/gogo.cc trunk/gcc/go/gofrontend/types.cc
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
