On 27.01.2016 16:10, Thorsten Otto wrote: > > This frobbing of a pointer return value in %d0 only happens in the > > outgoing case already now, because in the non-outgoing case, > > m68k_function_value is (unverified claim) only called from expand_call, > > which replaces the PARALLEL rtx by the first list element, i.e. %a0. (or > > %d0 if !POINTER_TYPE_P(valtype) after my patch). > > Wether pointer values are returned in d0 or a0 only depend on the ABI, > not the machine type. Well, this is kind-of correct. Of course the ABI defines whether pointers are returned in d0, a0 or rax. But the ABI depends on the machine type and is implemented by the machine-specific backend.
> > BTW what does ghc expect on x86-64? The ABIs on linux and e.g Win64 > are also quite different with respect to which registers are used to > pass/ parameters. The translation from Cmm to C only happens in "unregisterized" builds of ghc. In this kind of build, ghc has no specific expectations about what registers will be used for passing or returning value. The only thing ghc expects is that the code generated *by gcc* to retrieve the returned value (from a temporary memory location, an integer register, a floating-point register, an address register) for a function of type X called through a pointer-to-function-of-type-X matches the code generated *by gcc* to put that value into some registers. I trust gcc on Win64 and gcc on linux to know the specific ABIs and generate correct code. > And in the m68k-case, you will have similar problems with double > values. Depending on the ABI, they are returned in either fp0 or d0/d1. I already checked that, first experimentally, after that by reading the source code. There are no problems with returning double values, because the register picked for reading the return value from is determined by m68k_function_value using only the valtype parameter. This parameter indicates the actual return type when m68k_function_value is used while compiling the function and this parameter indicates the return type of the function-expression that acutally got called when compiling the caller. In the case of ghc, these types match, so a consistent register is returned (which depends on the ABI, though). > Conclusion: IMHO, If ghc fetches the return value from the wrong > register, then ghc is broken, not gcc. ghc does not fetch anything from any register. ghc generates C code that is known to be non-conforming, and gcc decides what register to fetch from. Regards, Michael Karcher
