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
18 matches
Mail list logo
