On 16/03/15 17:34, Marc Glisse wrote:
> On Mon, 16 Mar 2015, David Brown wrote:
>
>> In a discussion on comp.lang.c, the subject of "named parameters" (or
>> "designated parameters") has come up again. This is a feature that some
>> of us feel would be very useful in C (and in C++). I think it w
Hi,
I have a problem with a transformation pass I wrote.
The pass is meant to pipeline and unroll lookups in linked lists.
After my pass is run, gcc renames a variable, which leads to wrong results.
Part of my pass's dump, which is as I want it.
...
:
list_38 = list_10->next;
_22 = list_10
On 03/16/2015 09:45 PM, Ajit Kumar Agarwal wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Monday, March 16, 2015 11:45 PM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject
On March 17, 2015 3:37:25 PM GMT+01:00, Jeff Law wrote:
>On 03/16/2015 09:45 PM, Ajit Kumar Agarwal wrote:
>>
>>
>> -Original Message-
>> From: Jeff Law [mailto:l...@redhat.com]
>> Sent: Monday, March 16, 2015 11:45 PM
>> To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
>> Cc: Vinod
On 03/17/2015 06:32 AM, Benedikt Huber wrote:
Hi,
I have a problem with a transformation pass I wrote.
The pass is meant to pipeline and unroll lookups in linked lists.
After my pass is run, gcc renames a variable, which leads to wrong results.
Part of my pass's dump, which is as I want it.
..
Thank you for the answer.
I made sure that each variable is only assigned exactly once.
duplicate_block already generates new names for all lhs.
After that I edited all rhs to the uses I wanted for the unrolling,
so SSA-form should still be intact.
What I do not understand is: Why does gcc change t
On 03/17/2015 12:54 PM, Benedikt Huber wrote:
Thank you for the answer.
I made sure that each variable is only assigned exactly once.
duplicate_block already generates new names for all lhs.
After that I edited all rhs to the uses I wanted for the unrolling,
so SSA-form should still be intact.
Wh
07.03.2015 18:41, Jeff Law wrote:
> One potentially easy project there would be to take David Malcolm's work to
> turn the RTL EXPR & INSN lists into standard C++ forward lists.
Started working on this. I need to understand, if I'm moving in the
right direction (i.e. whether my understanding of wh
On 03/17/2015 09:50 PM, Mikhail Maltsev wrote:
07.03.2015 18:41, Jeff Law wrote:
One potentially easy project there would be to take David Malcolm's work to
turn the RTL EXPR & INSN lists into standard C++ forward lists.
Started working on this. I need to understand, if I'm moving in the
right
On Wed, Mar 18, 2015 at 06:50:11AM +0300, Mikhail Maltsev wrote:
> 07.03.2015 18:41, Jeff Law wrote:
> > One potentially easy project there would be to take David Malcolm's work to
> > turn the RTL EXPR & INSN lists into standard C++ forward lists.
>
> Started working on this. I need to understand
On 03/17/2015 10:32 PM, Trevor Saunders wrote:
2. Lists, list nodes and list iterators should be objects of distinct
types. In this case, header file function.h gets additional dependency,
because struct rtldata contains insn/expr lists as members; currently
they are pointers, so a forward decl
On Tue, Mar 17, 2015 at 10:36:05PM -0600, Jeff Law wrote:
> On 03/17/2015 10:32 PM, Trevor Saunders wrote:
> >
> >>2. Lists, list nodes and list iterators should be objects of distinct
> >>types. In this case, header file function.h gets additional dependency,
> >>because struct rtldata contains in
12 matches
Mail list logo
