This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Support non-standard extension (call via casted function pointer)

On Tue, Jan 26, 2016 at 10:21 AM, John Paul Adrian Glaubitz
<> wrote:
> Hi Richard!
> On 01/26/2016 08:01 AM, Richard Biener wrote:
>>> I developed a gcc patch that does not change the code generation for
>>> conforming programs but fixes this non-conforming use-case by always
>>> taking the actual return type in the call expression into account, even
>>> if the function declaration to be called is known. Please comment
>>> whether such a patch has any chance to be applied to either gcc
>>> upstream
>>> or gcc in Debian.
>> Without looking at the patch this is already how GCC should behave for all targets.
> So, would you actually favor the inclusion of Michael's changes?

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.

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

So, hookize and change to

  if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func))))
  else if (POINTER_TYPE_P (valtype))


> Having gcc allow to work with such code would actually allow us
> to bootstrap ghc on m68k again which would be awesome :).
> Adrian
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer -
> `. `'   Freie Universitaet Berlin -
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]