Snapshot gcc-4.9-20160127 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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 11 November 2015 at 19:04, Richard Biener wrote:
> On Wed, 11 Nov 2015, Prathamesh Kulkarni wrote:
>
>> On 11 November 2015 at 16:03, Richard Biener wrote:
>> > On Wed, 11 Nov 2015, Prathamesh Kulkarni wrote:
>> >
>> >> On 10 November 2015 at 20:11, Richard Biener wrote:
>> >> > On Mon, 9 Nov
Hi Guys,
First of all I have an apology to make. I managed to reformat my
hard drive over the holidays, wiping away all of my notes for this
blog. In particular I was contacted by a reader about an
enhancement to gcc's inline assembler support which I have now
totally lost. :-( So, de
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
...
>
11 matches
Mail list logo
