Re: Ask for copyright assignment forms for gcc
Eric Fisher writes: > It will be appreciated if anyone could help send me the copyright > assignment forms. I need them to submit patches to gcc. I think it > should be an assignment for all future changes. Sent offlist. Ian
[gengtype] are mark_hook GTY still working? Perhaps not!
Hello All,
The gengtype utility permits mark_hook-s.
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
>
> mark_hook ("hook-routine-name")
> If provided for a structure or union type, the given
> hook-routine-name (between double-quotes) is the name of a
> routine called when the garbage collector has just marked the
> data as reachable. This routine should not change the data, or
> call any ggc routine. Its only argument is a pointer to the
> just marked (const) structure or union.
I am quite sure that at some point in the past, the mark_hook did work.
But I have the impression that with the current gengtype, they don't.
The MELT branch & plugin needs them (and I believe I have contributed to
add this feature to gengtype). I really hope this feature will stay in
4.6!
The MELT's gcc/melt-runtime.h file uses it
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-runtime.h?revision=162077&view=markup
But gengtype generated code don't contain any melt_mark [MELT's
gcc/melt/generated/gt-melt-runtime-plugin.h file]
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt/generated/gt-melt-runtime-plugin.h?revision=162179&view=markup
Does any one have a working example of mark_hook GTY?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
>
Re: onlinedocs/libstdc++ apperas stale (was: [doc,patch] Move from GFDL 1.2 to GFDL 1.3)
> I guess what we should rather do is copying over the .html files from > the temporary directory into the web tree and then do the compressing > in the web tree. But I assume you guys on the libstdc++ side are a > lot more familiar with this, so it's your call. I guess what we should rather do is just try to get libstdc++ docs mainstreamed. What I would really like is http://gcc.gnu.org/onlinedocs/ to have # GCC 4.5.0 libstdc++ API Reference (also in PDF/PostScript/HTML) link to ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-api-20100707.html.tar.bz2 ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-api-20100707.pdf.bz2 # GCC 4.5.0 libstdc++ Manual (also in PDF/PostScript/HTML) ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-manual-20100707.html.tar.bz2 ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-manual-20100707.pdf.bz2 etc. (but for 4.5.x) I would rather move to this structure for release documentation. And then just have some nightly run on gcc.gnu.or on a properly configured machine that just generates the documentation directly from the sources. -benjamin
Re: GFDL/GPL issues
> In a biweekly call with the other GCC Release Managers, I was asked > today on the status of the SC/FSF discussions re. GFDL/GPL issues. In > particular, the question of whether or not we can use "literate > programming" techniques to extract documentation from code and take > bits of what is currently in GCC manuals and put that into comments > in code and so forth and so on. Hey Mark. Sorry, I was just pointed at this thread. Is there a separate issue for libstdc++ doxygen? This situation is subtly different from the one outlined above: it is the application of a GPL'd tool over GPL'd sources, which the FSF + Red Hat legal have both told me for years results in GPL'd docs (and is clearly noted as such in the libstdc++ manual under Licensing.) I consider this sane, actually, and would be most unhappily surprised if the act of generating the HTML changed the license to GFDL. It would be my preference to keep this, and then have Debian/Eclipse use dual GPL/GFDL or GFDL exclusive docs for specified releases of GCC, ie gcc-4.5.0-manual.gfdl.html.tar.bz2 etc. Anyway. Not trying to be controversial here, just trying to make existing (and hoped-for) usage clear. -benjamin
Re: [RFC] dotgen: Generate Graphiviz format .dot dump of functions cfg
On Mon, Jul 12, 2010 at 1:59 AM, Dennis, CHENG Renquan
wrote:
> From: Dennis, CHENG Renquan
>
> The GCC has default support of dumping gimple cfg in vcg format, but when I
> was trying to find a tool to interpret the *.006t.vcg dump file, or to
> generate
> a vector image format, it seemed not easy, the vcgviewer [1] not mature as
> Graphviz, and Graph::Easy [2] is a perl CPAN module, but why not add a pass
> to generate Graphviz .dot format default? These days it seems Graphviz is more
> popular;
>
> [1] http://code.google.com/p/vcgviewer/
> [2] http://search.cpan.org/~tels/Graph-Easy/
>
> This is a tentative implementation on dumping ".dot" files directly,
I've found the best place to add Graphviz dot format may be the graph.c file,
static const char *const graph_ext[] =
{
/* no_graph */ "",
/* vcg */ ".vcg",
};
maybe I could add one more format ".dot" support, like:
static const char *const graph_ext[] =
{
/* no_graph */ "",
/* vcg */ ".vcg",
/* dot */ ".dot",
};
Someone please recommend a good vcg format manipulate or conversion
program, if you know one, as long as is also free software; to stop my
work on the dot format support; my only incentive is that i cannot
find a good vcg => {ps,svg,png,...} conversion tool;
Thank you;
