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
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
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."
> > 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?
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 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
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).
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 26.01.2016 10:41, Andreas Schwab wrote:
> Except on ppc64le, until someone came along and changed the lie to a
> different lie. So why not lie a little different still, given you know
> you have crap code?
Before the ppc64le problem was fixed, there actually were two lies,
which was reduced to
On 26.01.2016 10:42, Andreas Schwab wrote:
> Michael Karcher writes:
>> ghc does not have the information yet when it writes the
>> declaration.
> It knows it when it calls the function, so that's a lame excuse.
The excuse is not as lame as it sounds at the first sight. In Cmm, the
following code
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 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 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 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 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.
Michael Karcher writes:
> ghc does not have the information yet when it writes the
> declaration.
It knows it when it calls the function, so that's a lame excuse.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And no
John Paul Adrian Glaubitz writes:
> I think you are missing the point, Andreas. Absolutely no one is
> argueing that the code in question is not valid. The point is, however,
> that this type of code does exist in the real world and runs fine
> on any architecture except m68k due the fact that we
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 26.01.2016 00:39, Andreas Schwab wrote:
> Michael Karcher writes:
>
>> *can't* (forward-)declare a function without fixing the return type.
> What does "fixing the return type" mean in the context of lying to the
> compiler?
OK, now I get your question. I don't mean fix in the sense of "repair"
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
On 01/26/2016 12:39 AM, Andreas Schwab wrote:
> Michael Karcher writes:
>
>> *can't* (forward-)declare a function without fixing the return type.
>
> What does "fixing the return type" mean in the context of lying to the
> compiler?
I think you are missing the point, Andreas. Absolutely no one
Michael Karcher writes:
> *can't* (forward-)declare a function without fixing the return type.
What does "fixing the return type" mean in the context of lying to the
compiler?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276
On 25.01.2016 23:07, Andreas Schwab wrote:
> Michael Karcher writes:
>> but it fixes the return type to some pointer type.
> Why does it do that?
Please help me understand why the sentence before the sentence you
quoted is not an answer to your question:
| This is because its internal Cmm (a C--
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
55 matches
Mail list logo
