This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gimple vs gimple_seq in 4.8 trunk

Hello All

I just merged the trunk (svn rev 187397) into the MELT branch (svn 187401) 
and I of course noticed the merging of gimple_seq into gimple (dated 2012-05-03).

However, the type gimple_seq still appears in a lot of source files 
(mostly gcc/gimple*.c & gcc/tree*.c)

Is this intended, or is this a temporary situation, and 
further patches would remove all occurrences of gimple_seq everywhere?

If it is intended, I would really like (probably in coretypes.h near 
the "typedef gimple gimple_seq;" line 75, or perhaps in gimple.h) 
a one paragraph comment explaning when a coder should write gimple_seq and when 
a coder should write just gimple.

If the goal is to get rid of gimple_seq completely, I suggest at least 
adding a comment in coretypes.h about that, and I hope that other patches will reduce the 
number of gimple_seq occurrences in gcc/*.c

In other words, when is it good taste to write gimple in some GCC code, 
and when is it good taste to write gimple_seq? Even if the types are 
identical from the compiler (building GCC from source) point of view, 
are these types identical for us?

If gimple is really identical to gimple_seq, I think we should get 
rid of the gimple_seq identifier (and replace it everywhere with gimple). 
Otherwise, that means that the gimple_seq name bears some (human) meaning 
different of gimple. Then we should document, at least in comments, and 
preferably also in gcc/doc/gimple.texi the meaning of each.

Having both identifiers gimple & gimple_seq conveying the same meaning would be 
confusing, especially to plugin writers (who have less familiarity with GCC internals 
than we do).

email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]