>
> Areas that are confusing and need clean up (IMO) include:
> 1) handling of aliases and clones
I am slowly cleaning up alias stuff, it had major reorg in 4.7 and further
cleanups in 4.8. Do you have more specific suggestions?
> 2) reachability, needed, analyzed bits. The needed bit is not i
On Wed, Sep 5, 2012 at 10:14 PM, Jan Hubicka wrote:
>> On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> >> On Sep 5, 2012 Jan Hubicka wrote:
>> >> > OK, the basic idea is that symtab_node is basetype of
>> >> > cgraph_node and varpool_node. We m
> On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
> > On 9/5/12, Xinliang David Li wrote:
> >> On Sep 5, 2012 Jan Hubicka wrote:
> >> > OK, the basic idea is that symtab_node is basetype of
> >> > cgraph_node and varpool_node. We may want to drop the historica
> >> > cgraph/varpool names
On Wed, Sep 5, 2012 at 9:38 PM, Jan Hubicka wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> > > On Sep 5, 2012 Jan Hubicka wrote:
>> > > > OK, the basic idea is that symtab_node is basetype of
>> > > > cgraph_node and varpool_node. We may want to drop the historica
>> > > > cgraph/varpool na
On Wed, Sep 5, 2012 at 9:32 PM, Jan Hubicka wrote:
>> On 9/5/12, Xinliang David Li wrote:
>> > On Sep 5, 2012 Jan Hubicka wrote:
>> > > OK, the basic idea is that symtab_node is basetype of
>> > > cgraph_node and varpool_node. We may want to drop the historica
>> > > cgraph/varpool names here,
On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
> On 9/5/12, Xinliang David Li wrote:
>> On Sep 5, 2012 Jan Hubicka wrote:
>> > OK, the basic idea is that symtab_node is basetype of
>> > cgraph_node and varpool_node. We may want to drop the historica
>> > cgraph/varpool names here, since
> > On 9/5/12, Xinliang David Li wrote:
> > > On Sep 5, 2012 Jan Hubicka wrote:
> > > > OK, the basic idea is that symtab_node is basetype of
> > > > cgraph_node and varpool_node. We may want to drop the historica
> > > > cgraph/varpool names here, since function_node/variable_node
> > > > would
>
> The cgraph redesign probably deserves more discussion.
>
> 1) It may be worthwhile to abstract the graph manipulation code into a
> utility class which is templatized.
>
> graph, node with node inheriting from T.
>
> 2) Introduce a global symbol table containing a function table and a
> g
> On 9/5/12, Xinliang David Li wrote:
> > On Sep 5, 2012 Jan Hubicka wrote:
> > > OK, the basic idea is that symtab_node is basetype of
> > > cgraph_node and varpool_node. We may want to drop the historica
> > > cgraph/varpool names here, since function_node/variable_node
> > > would sound bette
On 9/5/12, Xinliang David Li wrote:
> On Sep 5, 2012 Jan Hubicka wrote:
> > OK, the basic idea is that symtab_node is basetype of
> > cgraph_node and varpool_node. We may want to drop the historica
> > cgraph/varpool names here, since function_node/variable_node
> > would sound better. Cgraph st
On 9/5/12, Jan Hubicka wrote:
>> CONVERTERS AND TESTERS ###
>>
>> add
>> symtab_node_base &symtab_node_def::ref_symbol()
>> { return symbol; }
>> symtab_node_base &cgraph_node::ref_symbol()
>> { return symbol; }
>> symtab_node_base &var
On Wed, Sep 5, 2012 at 3:47 PM, Jan Hubicka wrote:
>> What do you think of the following plan for turning cgraph into
>> a class hierarchy? We cannot finish it until we have gengtype
>> understanding single inheritance, but we can start changing APIs
>> in preparation.
>
> Good you told me, I was
> What do you think of the following plan for turning cgraph into
> a class hierarchy? We cannot finish it until we have gengtype
> understanding single inheritance, but we can start changing APIs
> in preparation.
Good you told me, I was about trying that myself. Did not know gengtype
do not und
On 09/05/12 12:09, Iyer, Balaji V wrote:
I can't speak for the rest of the community, but I think items 1-12 are useful
for
GCC (elemental functions, SIMD annotations, and array notations for C/C++),
regardless of any language extensions. Perhaps you could provide examples on
these as a start
On 09/05/2012 12:59 PM, Joseph S. Myers wrote:
Regarding the patch ordering you list, note that earlier patches may not
be reviewable without later ones (specifically, code changes can only be
reviewed given documentation and testcases - in some cases documentation
might be external, but it does
Hello Joseph,
Please see my response below.
Thanks,
Balaji V. Iyer.
>-Original Message-
>From: Joseph Myers [mailto:jos...@codesourcery.com]
>Sent: Wednesday, September 05, 2012 3:00 PM
>To: Iyer, Balaji V
>Cc: Aldy Hernandez; 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com
>Subject
On Wed, 5 Sep 2012, Basile Starynkevitch wrote:
> Well, to take a concrete example, I don't understand well how on
> Debian/Sid can I know that the gcc-4.6-plugin-dev package is for
> x86-64-unknown-linux. the files provided by that package don't tell
> much.
The plugin itself shouldn't need t
On Wed, 5 Sep 2012, Iyer, Balaji V wrote:
> If this is OK with everyone, I will start sending patches to
> gcc-patches mailing list soon.
Regarding the patch ordering you list, note that earlier patches may not
be reviewable without later ones (specifically, code changes can only be
revi
What do you think of the following plan for turning cgraph into
a class hierarchy? We cannot finish it until we have gengtype
understanding single inheritance, but we can start changing APIs
in preparation.
EXISTING ###
enum symtab_type { SYMTAB_SYMBOL, SY
On Wed, Sep 05, 2012 at 03:14:40PM +, Joseph S. Myers wrote:
> On Wed, 5 Sep 2012, Basile Starynkevitch wrote:
>
> > const char* plugin_build_triplet (void);
>
> I think if you want to tell the plugin about the build triplet in this
> sort of way, there is some fundamental confusion involv
Hello Aldy,
Thank you for responding. Please see my answers to your questions
embedded below.
If this is OK with everyone, I will start sending patches to
gcc-patches mailing list soon.
Thanks,
Balaji V. Iyer.
>-Original Message-
>From: Aldy Hernandez [mailto:al...@r
On Wed, 5 Sep 2012, Basile Starynkevitch wrote:
> const char* plugin_build_triplet (void);
I think if you want to tell the plugin about the build triplet in this
sort of way, there is some fundamental confusion involved. A compiler
built for a given host and target pair should behave the sam
Hello All,
In http://gcc.gnu.org/ml/gcc/2012-08/msg00339.html Ian Taylor wrote:
> In general I would support having ways for plugins to detect this sort
> of thing, perhaps simply by making the build, host, and target triplet
> strings available to the plugin in some way.
I would like to get th
23 matches
Mail list logo
