GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès-4]

Hello,

For the interested reader, I eventually solved the nested function issue
by using either nested functions or C++11 lambdas, depending on whether
g++ is being used [0].

This is abstracted away by these (surprisingly not-too-ugly) macros to
define a local function, and declare a function parameter:

  #ifdef __cplusplus

  /* G++ doesn't implement nested functions, so use C++11 lambdas instead.  */

  # include <functional>

  # define local_define(ret, name, parms)     auto name = [=]parms
  # define function_parm(ret, name, parms)    std::function<ret parms> name

  #else  /* !__cplusplus */

  /* GNU C nested functions.  */

  # define local_define(ret, name, parms)     ret name parms
  # define function_parm(ret, name, parms)    ret (*name) parms

  #endif /* !__cplusplus */

They are used like this:

  static tree
  map (function_parm (tree, func, (const_tree)), tree t)
  {
    [...]
  }

  static tree
  foo (tree lst, tree y)
  {
    local_define (tree, frob, (const_tree x))
    {
      return do_something (x, y);
    };

    return map (frob, lst);
  }

Then there were other subtleties to work around, such as the lack of
support for designated initializers in g++.

Thanks,
Ludo’.

[0] https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?root=starpu&r1=6225&r2=6226

[Richard Guenther-2]

2012/3/19 Ludovic Courtès <ludovic.courtes@...>:

> Hi,
>
> Richard Guenther <richard.guenther@...> skribis:
>
>> But no, I'm not volunteering (I'm volunteering to do the review work).
>> The above has the same issue as the "we-want-to-be-more-like-LLVM"
>> stuff - it lacks the people to actually implement it, and GCC at its
>> present state still has to evolve, we can't and do not want to just spend
>> a complete release or two with just turning GCC upside-down.
>
> What David proposes looks great, but also fairly intrusive and
> development-intensive.
>
> Perhaps a more incremental approach could be taken.  For instance, I
> would argue that changes to the tree and GIMPLE APIs could be made
> conservatively, on the grounds that they are most likely used by
> plug-ins out there.  IOW, rather than a commitment to a stable API,
> which would hinder the work of GCC developers, this would be an informal
> agreement to not make the plug-in developers life too hard.
>
> In the example of name mangling, I’d just have wrapped in ‘extern "C"’
> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The
> rationale is that it simplifies plug-in maintenance, while not impeding
> development work in 4.7.

Well, that's _all_ headers.  Basically.  And exactly the problem.  There
will be never even API compatibility between major releases of GCC
with the current plugin "API".

Richard.

[Gabriel Dos Reis]

On Mon, Mar 19, 2012 at 10:36 AM, Ludovic Courtès
<ludovic.courtes@...> wrote:

> Perhaps a more incremental approach could be taken.  For instance, I
> would argue that changes to the tree and GIMPLE APIs could be made
> conservatively, on the grounds that they are most likely used by
> plug-ins out there.

Hmm, this is exactly the argument that people objected to
back in the days when there were talks of plug-ins.  The
existence of plugins should not be a hindrance on evolving
GCC internals.

> IOW, rather than a commitment to a stable API,
> which would hinder the work of GCC developers, this would be an informal
> agreement to not make the plug-in developers life too hard.

-- Gaby

[Ludovic Courtès-4]

Hi Richard,

Richard Guenther <richard.guenther@...> skribis:

> 2012/3/19 Ludovic Courtès <ludovic.courtes@...>:

[...]

>> In the example of name mangling, I’d just have wrapped in ‘extern "C"’
>> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The
>> rationale is that it simplifies plug-in maintenance, while not impeding
>> development work in 4.7.
>
> Well, that's _all_ headers.  Basically.

Well, these headers get installed, and they get installed to be actually
used, don’t they?  :-)

> And exactly the problem.  There will be never even API compatibility
> between major releases of GCC with the current plugin "API".

My experience is more encouraging: between 4.5 and 4.6, I was only hit
by a couple of tree.h declarations found in one and not the other.

When switching to 4.7, the main problem was mangled names, and all the
problems that making my code compilable with g++ entails.  Other issues
were the removal of the ‘built_in_decls’ array, and the new
‘affects_type_identity’ field of ‘attribute_spec’.

All this is summarized in the Autoconf macro I use [0]:

  dnl   build_call_expr_loc_array -- not in GCC 4.5.x; appears in 4.6
  dnl   build_call_expr_loc_vec   -- likewise
  dnl   build_array_ref           -- present but undeclared in 4.6.1
  dnl   build_zero_cst            -- not in GCC 4.5.x; appears in 4.6
  dnl   builtin_decl_explicit     -- new in 4.7, replaces `built_in_decls'
  dnl   .affects_type_identity    -- new field in 4.7

Then again, my plug-in is relatively small, and uses a small part of GCC.
Plug-ins with a larger API footprint may have more problems, of course.

Thanks,
Ludo’.

[0] https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&root=starpu

[Richard Guenther-2]

On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès
<ludovic.courtes@...> wrote:

> Hi Richard,
>
> Richard Guenther <richard.guenther@...> skribis:
>
>> 2012/3/19 Ludovic Courtès <ludovic.courtes@...>:
>
> [...]
>
>>> In the example of name mangling, I’d just have wrapped in ‘extern "C"’
>>> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The
>>> rationale is that it simplifies plug-in maintenance, while not impeding
>>> development work in 4.7.
>>
>> Well, that's _all_ headers.  Basically.
>
> Well, these headers get installed, and they get installed to be actually
> used, don’t they?  :-)
>
>> And exactly the problem.  There will be never even API compatibility
>> between major releases of GCC with the current plugin "API".
>
> My experience is more encouraging: between 4.5 and 4.6, I was only hit
> by a couple of tree.h declarations found in one and not the other.
>
> When switching to 4.7, the main problem was mangled names, and all the
> problems that making my code compilable with g++ entails.  Other issues
> were the removal of the ‘built_in_decls’ array, and the new
> ‘affects_type_identity’ field of ‘attribute_spec’.
>
> All this is summarized in the Autoconf macro I use [0]:
>
>  dnl   build_call_expr_loc_array -- not in GCC 4.5.x; appears in 4.6
>  dnl   build_call_expr_loc_vec   -- likewise
>  dnl   build_array_ref           -- present but undeclared in 4.6.1
>  dnl   build_zero_cst            -- not in GCC 4.5.x; appears in 4.6
>  dnl   builtin_decl_explicit     -- new in 4.7, replaces `built_in_decls'
>  dnl   .affects_type_identity    -- new field in 4.7
>
> Then again, my plug-in is relatively small, and uses a small part of GCC.
> Plug-ins with a larger API footprint may have more problems, of course.

I think it would be nice if you guys (plug-in makers) document what part
of the (non-)API you are using currently.  Document it on the GCC wiki
for example.  This way providing an initial guess for a real C plugin API
would be easier (and we'd get testing coverage).  I would even allow
such API be backported to the release branch(es) (given volunteers
to backport it).

We need to get started at some point - otherwise it will be just repeating
discussions.

If you have a copyright assignment on file (yeah, I guess even a set
of functions that just wrap existing gimple needs that) you might even
start at implementing such interface.  It might turn out as a convenient
library for plugin developers first.

Thanks,
Richard.

> Thanks,
> Ludo’.
>
> [0] https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&root=starpu

[Basile Starynkevitch]

On Tue, 20 Mar 2012 18:39:40 +1000
Peter Dolding <oiaohm@...> wrote:
>
> The top level modules already exist and are named.


Not really. I see nowhere on the GCC site a picture as clear as
the "plateform overview" figure on http://developer.gnome.org/
And I am not able to list and name corresponding modules.
If you do, please send a link or make an exhaustive list.

The internal executables like cc1 are too high.

For example, my feeling is that GCC (actually cc1) is made of three layers

front-ends  |  middle-end    |  back-ends

and I might consider that the middle-end contains perhaps the following modules

   the pass manager
   the simple gimple passes
   the IPA gimple passes

(but I am not even sure).

I really would like some global reviewer propose a whole list of (say a dozen or two, but
no more) modules to start the discussion.

If we had a picture like the platform overview picture for Gnome/GTK we could tell that
proeminently on our web site.

In some of the slides on http://gcc-melt.org/ you could find the attached picture (I
don't know if gcc@... accept attachments, apparently not in PDF) which you could
browse at http://gcc-melt.org/cc1-internals.pdf or http://gcc-melt.org/cc1-internals.svg
(CC BY SA license)

And this picture contain no module names, because I don't know of any. It is sadly not
enough precise because I am unable to list the set of modules making GCC (or just cc1)

Most importantly, no text inside our source distribution or our SVN repository seems to
list clearly an exhaustive list of *named* modules, and for each module the directory (or
set of source file names) making that module.

At last, I do feel important that every source file should be documented as part of a
given named module (e.g. by a comment just after the GPLv3 license paragraph), and
preferably that we would use some device -either a prefix à le GTK, or just a C++
namespace to remind to which module any public identifier belongs.

We have none of them. Actually, I even don't understand if we have a tentative list of
(one or two dozen) modules; with a name and a one sentence description or title. I am
not aware of such a list. If you have it, please publish it (or a link to it). And if
that list already exist, I strongly suggest that it should be added into the svn trunk
repository, as a README-GCC-MODULES file or whatever.


If you have an exhaustive list of modules making cc1, please tell.

Regards.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

[Peter Dolding-3]

On Wed, Mar 21, 2012 at 3:47 AM, Basile Starynkevitch
<basile@...> wrote:

> On Tue, 20 Mar 2012 18:39:40 +1000
> Peter Dolding <oiaohm@...> wrote:
>>
>> The top level modules already exist and are named.
>
>
> Not really. I see nowhere on the GCC site a picture as clear as
> the "plateform overview" figure on http://developer.gnome.org/
> And I am not able to list and name corresponding modules.
> If you do, please send a link or make an exhaustive list.
>
> The internal executables like cc1 are too high.
>
> For example, my feeling is that GCC (actually cc1) is made of three layers
>
> front-ends  |  middle-end    |  back-ends

Back-ends are shared between all languages gcc supports but can be
target particular..  So they are already a kind of module in there own
right.

Middle-end is language neutral.  Yes these are basically already a
module just not broken down enough.

front-ends part in cc1 is the only part that is fully unique to cc1.
The middle-end and back-ends you will find used with other languages
as is.

This here is a very good read.
http://www.cse.iitb.ac.in/grc/intdocs/gcc-conceptual-structure.html

For the official harder to read form
http://gcc.gnu.org/onlinedocs/gccint.pdf   basically this really needs
some graphics added.  And a little sorting.  But the same information
is in there as the gcc conceptual structure write up.

Even better gccint.pdf goes into what c files should be in each module.

This is why you hitting the wall that gcc is already kinda module
design.  Everything is sorted to go into modules is just starting
cutting.

Note I said exist and named.  I did not say they were into a simple to
read graphic on the gcc site.

Peter Dolding

[Richard Guenther-2]

On Wed, Mar 21, 2012 at 10:36 AM, Peter Dolding <oiaohm@...> wrote:

> On Wed, Mar 21, 2012 at 3:47 AM, Basile Starynkevitch
> <basile@...> wrote:
>> On Tue, 20 Mar 2012 18:39:40 +1000
>> Peter Dolding <oiaohm@...> wrote:
>>>
>>> The top level modules already exist and are named.
>>
>>
>> Not really. I see nowhere on the GCC site a picture as clear as
>> the "plateform overview" figure on http://developer.gnome.org/
>> And I am not able to list and name corresponding modules.
>> If you do, please send a link or make an exhaustive list.
>>
>> The internal executables like cc1 are too high.
>>
>> For example, my feeling is that GCC (actually cc1) is made of three layers
>>
>> front-ends  |  middle-end    |  back-ends
>
> Back-ends are shared between all languages gcc supports but can be
> target particular..  So they are already a kind of module in there own
> right.
>
> Middle-end is language neutral.  Yes these are basically already a
> module just not broken down enough.
>
> front-ends part in cc1 is the only part that is fully unique to cc1.
> The middle-end and back-ends you will find used with other languages
> as is.
>
> This here is a very good read.
> http://www.cse.iitb.ac.in/grc/intdocs/gcc-conceptual-structure.html
>
> For the official harder to read form
> http://gcc.gnu.org/onlinedocs/gccint.pdf   basically this really needs
> some graphics added.  And a little sorting.  But the same information
> is in there as the gcc conceptual structure write up.
>
> Even better gccint.pdf goes into what c files should be in each module.
>
> This is why you hitting the wall that gcc is already kinda module
> design.  Everything is sorted to go into modules is just starting
> cutting.
>
> Note I said exist and named.  I did not say they were into a simple to
> read graphic on the gcc site.

Indeed.  There is also different module hierarchies that overlap.  For
example ILs used in the different parts of the compiler.

I think Basile is mostly confused about what files belong to what module,
a question with not a single answer per file.  It's been suggested before,
but moving files into subdirectories might help here, at least for those
which have a clearly defined module.  The C frontend is one obvious
example, generator programs for machine descriptions another,
RTL optimization passes are harder, GIMPLE/SSA optimization
passes are somewhat hard, ... there is not always a good directory
to put things in.  For example I absolutely hate the suggested gimple/

Richard.

> Peter Dolding

[Peter Dolding-3]

On Wed, Mar 21, 2012 at 7:57 PM, Richard Guenther
<richard.guenther@...> wrote:

> Indeed.  There is also different module hierarchies that overlap.  For
> example ILs used in the different parts of the compiler.
>
> I think Basile is mostly confused about what files belong to what module,
> a question with not a single answer per file.  It's been suggested before,
> but moving files into subdirectories might help here, at least for those
> which have a clearly defined module.  The C frontend is one obvious
> example, generator programs for machine descriptions another,
> RTL optimization passes are harder, GIMPLE/SSA optimization
> passes are somewhat hard, ... there is not always a good directory
> to put things in.  For example I absolutely hate the suggested gimple/
>
> Richard.

I see all the IL as storage/modules.  That transfer data between modules.

Breaking into modules does not mean a module cannot be dependant on a
different one.

So we could have a stack of modules dependant on particular IL module.

So Generic IL, Gimple IL, RTL IL would have modules in there own right
containing the code shared between optimisers and the like.

SSA processing of Gimple if the functions it using is used by nothing
else its SSA code.

Taking what gcc is and making into modules is just takes obeying a few
simple rules.

1 imports into your section have to come from other modules not lossy
shared files.(current confusion is lossy shared files)
2 there is no such thing as grey.  If a file is shared between two
modules it must be in a third module.   If file exists in both modules
you have split incorrectly.

If there is a grey area you have broken into modules wrong.  Module
based code has no grey.  No grey equals less errors of person editing
a file they think is exclusive to some part that turns out to be
shared with another part so causing nasty failure.

Like Gimplification has to be dependant on two modules for C.  Generic
IL and Gimple IL.  Most diagrams currently try to put it either in
front end or middle end.  When in fact its the bridge module between
front end and back end and its accessing data from both sides.

Once you start breaking modules correctly.  SSA is simple its just SSA.

With correct modules knowing what you are going to ruin by touching a
file become simpler.

So yes there should be a gimple/ directory but it should only contain
the shared functions and the internal code those shared functions use
to drive the gimple IL.  Repeat the same for RTL and Simple.

If you have broken everything right you should basically be able to
pull off building all the modules as .so/.dll files bar the core
application and have application work.

There should be a single answer per file Richard Guenther.  It is
critical there is.  So you know what you are working on.

Of course there are going to be a few files as cutting starts where if
we do a detailed design straight up when cutting starts its going to
be o bugger we need to create another module here so the code base is
clean.

We have the basic overview.  The question is were to start cutting.
Cutting front end stuff that is obvious would be a very good starting
point.

I don't expect gcc hierarchies to be a nice clean shape.  But it
should be able to be made cleaner.  So if I want to adjust like a
front end I know I am adjusting just the front end not something else.
 Same with SSA that I am fixing a bug in SSA I know that the files I
am currently touching SSA only uses.

Finally I know if I am playing in any of the IL directories I am
playing with fire.

Of course with SSA it might have subdirectories under it for code
sections that can be edited without effecting everything.   This is
where breaking into modules is good you can see how much risk you are
taking.

Personally in my eyes it time to start cutting into directories and
shaping the code up to neat.  Remove the left over layout from prior
to IL being used a lot inside gcc.

Basically we have the overview roughly how the code should look when
modules.  The final overview of the code as modules can only be done
after its chopped up into modules.   There is no requirement to chop
it all at once.  Trying to chop it all at once may not give enough
time to work out how to correctly cut any overlapping parts that turn
up.

So realistic goal should be a particular area chopped correctly.  Each
chop equals altering makefiles and moving files.  Slow can careful is
required when doing this is required.  Each chop could bring failure.
A chop per point release most likely would be too careful.

Basically Gcc 5=modular should a little of an extrema goal when we
have not made a decent percentage modular yet.   We have to get to
proper half or more modules before we really should set a goal like
this.  Once there is a clearer idea of the issues that will happen.

Peter Dolding

[Pedro Lamarão-6]

Em 21/03/2012 08:58, Peter Dolding escreveu:

> If there is a grey area you have broken into modules wrong.  Module
> based code has no grey.  No grey equals less errors of person editing
> a file they think is exclusive to some part that turns out to be
> shared with another part so causing nasty failure.

This seems a Game of Words [tm].

Of course a modularized system can have a grey area. You just pack all
of your gray area files and call them "grey module" to satisfy the
bureaucracy.

There is no perfect taxinomy in this world. Searching for one is
interesting; demanding one is useless.

--
  P.

[Basile Starynkevitch]

On Wed, Mar 21, 2012 at 10:57:08AM +0100, Richard Guenther wrote:
>
> Indeed.  There is also different module hierarchies that overlap.  For
> example ILs used in the different parts of the compiler.
>
> I think Basile is mostly confused about what files belong to what module,
> a question with not a single answer per file.  It's been suggested before,


Sorry people, we don't have any established list of named modules. I see
nowhere a list of one or two dozens of modules with for each of them:

  * a name

  * short description in one or two sentences

  * the entire set of files or directories implementing that module

  * the API of that module (perhaps as a public header file, with the strong
    requirement that internal functions should be declared in a private header
    file)

Again, I take as a good example GTK/Gnome. It has a documented set of named
modules, there is a figure explaining their organization and a table listing
all of them, and each module has a documentation and a set of header files
defining its interface. It has also a naming convention: in C, all the
public identifiers of a module starts by the same prefix (e.g.
GtkSourceView); in C++ the interface is inside a single C++ namespace. At
last, it has a crystal clear file heararchy which, for a given file, makes
finding to which module it belongs very easy (often the parent or
grand-parent directory gives the name of the module).

So far, I was not even able to find a list of modules names of GCC. and for
each module, the set of source files implementing it (and the set of public
header files defining its interface at the very least).

And no reply even mentionned any module names. We badly need that some
people with a *global* understanding of GCC (these are few, I am not of
them) propose a list of module *names* to be discussed.


For exmpla, I have absolutely no idea if the register allocator is one
module (or perhaps two, and probably none) or if it is just part of the
backend RTL passes


I'm quite surprised no one mentionned how it is difficult to explain GCC to
a newscomer (e.g. some student wanting to work on GCC within a GSOC). This
is partly the case because we cannot make a short list of modules. And to
ease the understanding effort, that list should be reasonably short. We
should have a list of 7-30 modules at most (I agree that some of these
modules could be further defined as made of several sub-modules). And each
of these modules should have a unique name. Each of these modules should
also have a small "title" sentende describint what it does (in a dozen
English words). At last, such a description should be part of the internal
documentation. http://gcc.gnu.org/onlinedocs/gccint/ should have a chapter
(probably after "3. http://gcc.gnu.org/onlinedocs/gccint/Interface.html")
perhaps titled "organization of GCC in toplevel-modules" explaining all
this.

We are far from that. We first need to discuss a set of proposed module
names and titles. (Unfortunately, I am not able to propose it, because I
don't have a global knowledge of GCC; I expecte the few "global reviewers"
to have enough such knowledge.)

Once we have a proposal for modules names and titles we can discuss them,
and dive more deaper into a modular organization of GCC. (I really think we
cannot discuss of things which stay ill-defined and un-named).

Regards.

PS. Again, I don't have a large enough knowledge of GCC to even propose a
list of modules.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Richard Guenther-2]

On Wed, Mar 21, 2012 at 4:02 PM, Pedro Lamarão
<pedro.lamarao@...> wrote:

> Em 21/03/2012 08:58, Peter Dolding escreveu:
>
>
>> If there is a grey area you have broken into modules wrong.  Module
>> based code has no grey.  No grey equals less errors of person editing
>> a file they think is exclusive to some part that turns out to be
>> shared with another part so causing nasty failure.
>
>
> This seems a Game of Words [tm].
>
> Of course a modularized system can have a grey area. You just pack all of
> your gray area files and call them "grey module" to satisfy the bureaucracy.
>
> There is no perfect taxinomy in this world. Searching for one is
> interesting; demanding one is useless.

Very well said.  Discussing about modules also makes no sense.  Figure out
the present state.

Richard.

> --
>  P.
>

[Gabriel Dos Reis]

On Wed, Mar 21, 2012 at 10:03 AM, Basile Starynkevitch
<basile@...> wrote:

> Sorry people, we don't have any established list of named modules. I see
> nowhere a list of one or two dozens of modules with for each of them:
>
>  * a name
>
>  * short description in one or two sentences
>
>  * the entire set of files or directories implementing that module
>
>  * the API of that module (perhaps as a public header file, with the strong
>    requirement that internal functions should be declared in a private header
>    file)

You appear to have a better understanding of what a module in GCC should be.
Would you mind leading the pack by sending patches for evaluation and review?
I am afraid an abstract lecture would not be enough.

-- Gaby

[Basile Starynkevitch]

On Wed, Mar 21, 2012 at 10:24:54AM -0500, Gabriel Dos Reis wrote:

> On Wed, Mar 21, 2012 at 10:03 AM, Basile Starynkevitch
> <basile@...> wrote:
>
> > Sorry people, we don't have any established list of named modules. I see
> > nowhere a list of one or two dozens of modules with for each of them:
> >
> >  * a name
> >
> >  * short description in one or two sentences
> >
> >  * the entire set of files or directories implementing that module
> >
> >  * the API of that module (perhaps as a public header file, with the strong
> >    requirement that internal functions should be declared in a private header
> >    file)
>
>
> You appear to have a better understanding of what a module in GCC should be.
> Would you mind leading the pack by sending patches for evaluation and review?
> I am afraid an abstract lecture would not be enough.
>

I am not sure what you expect from me. As I said many times, I have not a
global understanding of GCC (the "global reviewers" have a much better
global understanding than I do). So I cannot propose or initiate a list of
modules.

Or do you want me to just propose a documentation patch with a canvas or
frame for other poeple to fill?

I would be happy to help, but please understand that my understanding of GCC
is restricted to gengtype, ggc, and some parts of the middle-end. I know
nothing about the vast rest of the GCC compiler.

Cheers.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Peter Dolding-3]

On Thu, Mar 22, 2012 at 1:03 AM, Basile Starynkevitch
<basile@...> wrote:

> On Wed, Mar 21, 2012 at 10:57:08AM +0100, Richard Guenther wrote:
>>
>> Indeed.  There is also different module hierarchies that overlap.  For
>> example ILs used in the different parts of the compiler.
>>
>> I think Basile is mostly confused about what files belong to what module,
>> a question with not a single answer per file.  It's been suggested before,
>
>
> Sorry people, we don't have any established list of named modules. I see
> nowhere a list of one or two dozens of modules with for each of them:
>
>  * a name
>
>  * short description in one or two sentences
>
>  * the entire set of files or directories implementing that module
>
>  * the API of that module (perhaps as a public header file, with the strong
>    requirement that internal functions should be declared in a private header
>    file)
>

We have more than two dozen.

http://gcc.gnu.org/onlinedocs/gccint.pdf  again every header and dot
point in section 9 would be a module.

Then there is the supporting bits to those modules.like the IL's and
the runtime.

Section 9 is basically the abridged overview.  So there will be a lot
more modules than what is listed.

Yes what you describing is a clean up of gccint documentation to be
more readable and practical.

Also you are describing the chopping process.

Yes we do have a list of what is what in documentation.  Is is
currently really nice to use no its not.  Its it fully detailed as it
should be no its not.   Is the problem huge yes it is.  Breaking into
modules gcc will have a more complex layout than gnome does.   Due to
the way thing interact.  Most likely will not fit well into a 2d
graphic.  Most likely will fit well into a 3d graphic.

So yes gccint is the starting block.  Some are nicely described with
what functions own to the module some are not.  Imports and exports
are not well declared.

It is going to have to be a piece by peice prcoess

Peter Dolding

[Jonathan Wakely-4]

On 21 March 2012 15:35, Basile Starynkevitch wrote:
>>
>
> I am not sure what you expect from me. As I said many times, I have not a
> global understanding of GCC (the "global reviewers" have a much better
> global understanding than I do). So I cannot propose or initiate a list of
> modules.
>
> Or do you want me to just propose a documentation patch with a canvas or
> frame for other poeple to fill?

Why not start a wiki page?  There's no need for patch approval and
anyone can make edits to improve it gradually over time.  If the
initial version is wrong someone can change it, but at least it will
have been started.

[Robert Dewar]

> Very well said.  Discussing about modules also makes no sense.  Figure out
> the present state.

these kind of meta discussions are very rarely of value, this
one is no exception IMO
>
> Richard.
>
>> --
>>   P.
>>

[Robert Dewar]

On 3/21/2012 11:35 AM, Basile Starynkevitch wrote:

> I would be happy to help, but please understand that my understanding of GCC
> is restricted to gengtype, ggc, and some parts of the middle-end. I know
> nothing about the vast rest of the GCC compiler.

Perhaps suggestions about improvements in the modularity of
gcc would be better left up to those who DO have a global
understanding of the existing structure of gcc.

[Peter Dolding-3]

On Thu, Mar 22, 2012 at 8:51 AM, Jonathan Wakely <jwakely.gcc@...> wrote:

> On 21 March 2012 15:35, Basile Starynkevitch wrote:
>>>
>>
>> I am not sure what you expect from me. As I said many times, I have not a
>> global understanding of GCC (the "global reviewers" have a much better
>> global understanding than I do). So I cannot propose or initiate a list of
>> modules.
>>
>> Or do you want me to just propose a documentation patch with a canvas or
>> frame for other poeple to fill?
>
> Why not start a wiki page?  There's no need for patch approval and
> anyone can make edits to improve it gradually over time.  If the
> initial version is wrong someone can change it, but at least it will
> have been started.

Really it must happen at code level.  The advantage of modules is for
safer coding.

We have got stacks of docs written from the outside looking in.
Modules have to start in the code base.  Once it clear what is in a
module the module shape of the code base can be become stable.

gccint and work out a cut into a clear define module.  Create a
description for what has been cut.  Repeat.

Sooner or latter it will become module design.

The people who can review if a cut is sane are the ones working on the
code base.

This is the problem you can try to write a global list but until it in
the code base the global list will be open to change.

The gccint gives enough over view to start trying to plan a cut.

Really that the thing we need to focus on what will be the first module to make.

Peter Dolding