On January 26, 2016 8:03:35 PM GMT+01:00, Michael Karcher <deb...@mkarcher.dialup.fu-berlin.de> wrote: >On 26.01.2016 16:40, Richard Biener wrote: >> No, the patch looks somewhat broken to me. A complete fix would >replace >> the target macro FUNCTION_VALUE implementation by implementing the >> function_value hook instead (to also receive the function type called >if no >> decl is available and to be able to distinguish caller vs. callee). >> >> I also don't see how changing the called function code will fix >anything. >I definitely agree that the approach to move from the FUNCTION_VALUE >macro to the function_value hook is the most clean way to do it. If >there is a consensus among the gcc developers that a patch to support >this non-conforming code should be applied, I would be willing to >prepare a patch as suggested. > >The current patch does not change the called code at all. The only time >at which my suggested patch changes gcc behaviour is if a function >declaration is given, that declaration has a pointer type as return >type, but valtype is no pointer type. This (unverified claim) can not >happen in the callee, as the valtype when compiling the return >statement >or assembling the epilogue is taken from the function declaration. > >> In fact the frobbing of the return value into %d0 should only happen >> if the 'outgoing' arg is true (in the hook implementation) and in the >> 'outgoing' == false case simply disregard 'func' and always use >> 'valtype'. >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). > >> So, hookize and change to >> >> if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func)))) >> ... >> else if (POINTER_TYPE_P (valtype)) >> ... >> else >> ... >Looks good and clean to me, but I expect my patch to have the same >effect.
I would still prefer the more obvious approach of using the target hook transition. Richard. > >Regards, > Michael Karcher
