On Thu, 28 Jan 2016 19:10:03 +0100
Andreas Schwab wrote:
> Why does the dummy declaration need to use a pointer type?
Just a historical remnant.
Historically it was a single declaration used for both "known"
prototypes (for functions generated by GHC) and "unknown"
prototypes (arbitrary C funct
Eric Botcazou writes:
>> What about the prototype in raise.h?
>
> Yes, the C side knows the type, but not the Ada side, that's the problem.
??? Since they must agree they are the same.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5
> What about the prototype in raise.h?
Yes, the C side knows the type, but not the Ada side, that's the problem.
--
Eric Botcazou
Eric Botcazou writes:
>> See PR48835. The Ada situation is even worse, it doesn't even try to
>> cast the (wrongly declared) function to the correct type before calling
>> it.
>
> How could it, since it doesn't know the correct type of the function?
What about the prototype in raise.h?
Andreas
> See PR48835. The Ada situation is even worse, it doesn't even try to
> cast the (wrongly declared) function to the correct type before calling
> it.
How could it, since it doesn't know the correct type of the function? The way
out is to change the type of the function on the Ada side, as expl
Jeff Law writes:
> I know someone (probably Andreas) with some work was able to get GCC
> working with Ada. However, they didn't push to get all those changes
> upstreamed.
See PR48835. The Ada situation is even worse, it doesn't even try to
cast the (wrongly declared) function to the correct
On 01/28/2016 03:11 AM, Florian Weimer wrote:
On 01/27/2016 04:17 PM, Richard Biener wrote:
We are trying to support
t.c
---
void *foo();
int bar()
{
return ((int (*)())foo) ();
}
t2.c
-
int foo () { return 0; }
thus doing a direct call to a function with a (wrong) prototype via a fu
On 01/27/2016 03:07 PM, Michael Karcher wrote:
Why can't ghc produce code like:
int bar ()
{
int (*foo1)() = foo;
asm("":"+r"(foo1));
return foo1();
}
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm languag
Why does the dummy declaration need to use a pointer type?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On 28.01.2016 11:04, Andreas Schwab wrote:
> John Paul Adrian Glaubitz writes:
>
>> [suggestion to use "void" as dummy return type]
>>
>> Wait. Do you think this would actually allow ghc to determine the
>> return type later? If I remember correctly, ghc currently initially
>> declares the functio
> > package Import is
> >
> >function Foo return System.Address;
> >pragma Import (C, Foo);
> >
> >function Bar return Integer;
> >
> > end Import;
> >
> > package body Import is
> >
> >function Bar return Integer is
> > function Foo_2 return Integer;
> > pragma Imp
> I suspect Ada needs something like this already. I expect the following
> to work (although it is quite hideous).
>
> with System;
>
> package Import is
>
>function Foo return System.Address;
>pragma Import (C, Foo);
>
>function Bar return Integer;
>
> end Import;
>
> package b
On Thu, Jan 28, 2016 at 11:11 AM, Florian Weimer wrote:
> On 01/27/2016 04:17 PM, Richard Biener wrote:
>
>> We are trying to support
>>
>> t.c
>> ---
>> void *foo();
>>
>> int bar()
>> {
>> return ((int (*)())foo) ();
>> }
>>
>> t2.c
>> -
>> int foo () { return 0; }
>>
>> thus doing a direc
On 01/27/2016 04:17 PM, Richard Biener wrote:
> We are trying to support
>
> t.c
> ---
> void *foo();
>
> int bar()
> {
> return ((int (*)())foo) ();
> }
>
> t2.c
> -
> int foo () { return 0; }
>
> thus doing a direct call to a function with a (wrong) prototype via a function
> pointer c
John Paul Adrian Glaubitz writes:
> Wait. Do you think this would actually allow ghc to determine the
> return type later? If I remember correctly, ghc currently initially
> declares the function prototype with return type void*, doesn't it?
Replace a lie with a different lie. Spot the pattern?
On 01/28/2016 09:55 AM, Andreas Schwab wrote:
> Richard Biener writes:
>
>> I think that's reasonable and what GHC expects - declare "there is a function
>> foo defined, no idea what prototype yet", unfortunately C requires to specify
>> a return type.
>
> Like void, f.ex.
Wait. Do you think th
Richard Biener writes:
> I think that's reasonable and what GHC expects - declare "there is a function
> foo defined, no idea what prototype yet", unfortunately C requires to specify
> a return type.
Like void, f.ex.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA
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 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 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
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
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
...
>
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
>>>...
>> Looks good and clean to me, but I expect my patch to have the sam
On January 26, 2016 8:03:35 PM GMT+01:00, Michael Karcher
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 r
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
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
On 01/26/2016 03:59 AM, John Paul Adrian Glaubitz wrote:
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
John Paul Adrian Glaubitz writes:
Having gcc allow to work with such code would actually allow us
to bootstrap ghc on m68k again which would be awesome :).
The ghc code just needs to be fi
On 01/26/2016 02: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
On 01/26/2016 01:41 AM, Richard Biener wrote:
What I wanted to say is that we preserve the function type used for
the actual call at least until RTL expansion in gimple_call_fntype.
I fixed most of the call expansion code to honor that but back ends
may of course screw up as they still may someh
On Mon, Jan 25, 2016 at 10:47:10PM +0100, Michael Karcher wrote:
> Hello gcc developers,
>
> as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
> forwarded as PR c/69221), ghc generates non-compliant C code that is not
> compiled as intended on m68k. This is because its internal Cm
On 01/26/2016 12:07 PM, Andreas Schwab wrote:
>> If this bug is actually the same as the m68k bug,
>
> Where did I say that?
> The ghc code just needs to be fixed to not lie in such a blatant way.
> Just like it was changed when ppc64le flagged this as crap code.
John Paul Adrian Glaubitz writes:
> I could just find one bug report which mentions a fix for ppc64el [1],
> are you talking about this one?
Yes.
> If this bug is actually the same as the m68k bug,
Where did I say that?
> why is ghc still working fine on ppc64el?
Because ghc tweaked its crap
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
> John Paul Adrian Glaubitz writes:
>
>> Having gcc allow to work with such code would actually allow us
>> to bootstrap ghc on m68k again which would be awesome :).
>
> The ghc code just needs to be fixed to not lie in such a blatant way.
> Just lik
John Paul Adrian Glaubitz writes:
> Having gcc allow to work with such code would actually allow us
> to bootstrap ghc on m68k again which would be awesome :).
The ghc code just needs to be fixed to not lie in such a blatant way.
Just like it was changed when ppc64le flagged this as crap code.
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 de
On January 26, 2016 8:25:50 AM GMT+01:00, Jeff Law wrote:
>On 01/26/2016 12:01 AM, Richard Biener wrote:
>> On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
> wrote:
>>> Hello gcc developers,
>>>
>>> as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
>>> forwarded as PR c
On 26.01.2016 08:25, Jeff Law wrote:
> I believe if they make the return type a pointer type, then the m68k
> backend ought to return the value in a0 and d0 to make broken code
> like this work. It may also be the case that we're not doing this
> properly for indirect calls from a quick scan of m6
On 01/26/2016 12:01 AM, Richard Biener wrote:
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
wrote:
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is
not
compiled as intende
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
wrote:
>Hello gcc developers,
>
>as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
>forwarded as PR c/69221), ghc generates non-compliant C code that is
>not
>compiled as intended on m68k. This is because its internal Cmm
Michael Karcher writes:
> but it fixes the return type to some pointer type.
Why does it do that?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is not
compiled as intended on m68k. This is because its internal Cmm (a C--
dialect) to C compiler needs to declare external functions (no var
44 matches
Mail list logo
