On Wed, Jan 27, 2016 at 7:17 AM, Richard Biener
wrote:
> On Wed, Jan 27, 2016 at 4:10 PM, 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
On 01/27/2016 02:40 PM, Michael Karcher wrote:
On 27.01.2016 11:33, Richard Biener wrote:
On Tue, Jan 26, 2016 at 9:54 PM, Michael Karcher
wrote:
On 26.01.2016 21:47, Richard Biener wrote:
I would still prefer the more obvious approach of using the target hook
transition.
I intended to exp
On 27.01.2016 11:33, Richard Biener wrote:
> On Tue, Jan 26, 2016 at 9:54 PM, Michael Karcher
> wrote:
>> On 26.01.2016 21:47, Richard Biener wrote:
>>
>>> I would still prefer the more obvious approach of using the target hook
>>> transition.
>> I intended to express in my last email: Me too, an
On 27.01.2016 22:49, Andrew Pinski wrote:
> On Wed, Jan 27, 2016 at 7:17 AM, Richard Biener
> wrote:
>>
>> We are trying to support
>>
>> t.c
>> ---
>> void *foo();
>>
>> int bar()
>> {
>> return ((int (*)())foo) ();
>> }
> Why can't ghc produce code like:
> int bar ()
> {
> int (*foo1)() = fo
On 27.01.2016 16:40, Thorsten Otto wrote:
> > We are trying to support ... a direct call to a function with a
> (wrong) prototype via a function
> > pointer cast to the correct type and having a matching implementation of
> > that function elsewhere.
>
> Yes, i did understand that. But you are tryi
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 fi
> We are trying to support ... a direct call to a function with a (wrong)
> prototype via a function
> pointer cast to the correct type and having a matching implementation of
> that function elsewhere.
Yes, i did understand that. But you are trying to do that by hacking gcc's m68k
backend. I sti
On Wed, Jan 27, 2016 at 4:10 PM, 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
> 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_
On Tue, Jan 26, 2016 at 9:54 PM, Michael Karcher
wrote:
> On 26.01.2016 21:47, Richard Biener wrote:
So, hookize and change to
if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func
...
else if (POINTER_TYPE_P (valtype))
...
else
...
>
Michael Karcher writes:
> Before the ppc64le problem was fixed, there actually were two lies,
> which was reduced to just one lie: The first lie concerned the parameter
> list (claiming it would be empty) and the second lie concerned the
> return type (claiming it would be some function pointer).
11 matches
Mail list logo
