Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?
> MELT only need gengtype to generate its gt-melt-runtime.h but I have no idea > if that file depends upon the configuration (and notably the target for > which GCC is built). The GTY-ed data of MELT does not depend (IMHO) upon the > configuration directly (in the sense that there is no #ifdef around GTY-ed > struct), but of course it points to data like Gimple or Tree which I imagine > depend upon the configuration of GCC (notably --enable-check but perhaps > also the target ...) The gt-melt-runtime.h should only contain GC and PCH root information which shouldn't change between the configurations, so this file should be portable. OTOH, gtype-desc.h isn't. -- Laurynas
Re: Use the wctype builtins functions
On 03/05/2010 05:03 PM, Joseph S. Myers wrote:
I don't know if there's an existing free software implementation of UAX#14
(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be
the very heavyweight approach.
Yes. You can get it from gnulib like gdb does, or you can link
libunistring (http://savannah.gnu.org/projects/libunistring).
libunistring only supports UTF-{8,16,32} encodings though.
Paolo
[lto] elfutils-libelf-0.145 vs libelf-0.8.13?
hi, i would like to ask why the LTO forces libelf-0.8.x in configure.ac? linux/unix distros have well tested elfutils-libelf subpackage, so what is the point in forcing new library? i've just built (with little hack) gcc/trunk with elfutils-libelf and lto works fine. BR, Pawel.
Re: [lto] elfutils-libelf-0.145 vs libelf-0.8.13?
2010/3/11 Paweł Sikora : > hi, > > i would like to ask why the LTO forces libelf-0.8.x in configure.ac? > linux/unix distros have well tested elfutils-libelf subpackage, > so what is the point in forcing new library? > > i've just built (with little hack) gcc/trunk with elfutils-libelf > and lto works fine. > It doesn't force libelf for me: checking libelf.h usability... yes checking libelf.h presence... yes checking for libelf.h... yes checking gelf.h usability... yes checking gelf.h presence... yes checking for gelf.h... yes checking libelf/libelf.h usability... no checking libelf/libelf.h presence... no checking for libelf/libelf.h... no checking libelf/gelf.h usability... no checking libelf/gelf.h presence... no checking for libelf/gelf.h... no checking for the correct version of libelf... yes I am using elfutils-libelf 0.145. -- H.J.
Re: [lto] elfutils-libelf-0.145 vs libelf-0.8.13?
Dnia 11-03-2010 o 14:51:39 H.J. Lu napisał(a): checking for libelf/gelf.h... no checking for the correct version of libelf... yes I am using elfutils-libelf 0.145. ahh, right. i've accidentally used an older version 0.142 which libelf.h contains only: extern int elf_getshstrndx (Elf *__elf, size_t *__dst); the latest 0.145 have both signatures: extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst); ^ lto requires exactly this one. extern int elf_getshstrndx (Elf *__elf, size_t *__dst) __attribute__ ((__deprecated__)); sorry for the noise :)
Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?
Hello all,
On Thu, Mar 11, 2010 at 09:12:51AM +0100, Laurynas Biveinis wrote,
citing me Basile:
> > MELT only need gengtype to generate its gt-melt-runtime.h but I have no idea
> > if that file depends upon the configuration (and notably the target for
> > which GCC is built). The GTY-ed data of MELT does not depend (IMHO) upon the
> > configuration directly (in the sense that there is no #ifdef around GTY-ed
> > struct), but of course it points to data like Gimple or Tree which I imagine
> > depend upon the configuration of GCC (notably --enable-check but perhaps
> > also the target ...)
>
> The gt-melt-runtime.h should only contain GC and PCH root information
> which shouldn't change between the configurations, so this file should
> be portable. OTOH, gtype-desc.h isn't.
I was thinking of MELT as a *plugin*, so gengtype is invoked in plugin
mode, with -P, for instance like
./build/gengtype -P gt-melt-runtime-plugin.h gtyp-input.list \
$MELT_PLUGIN_SOURCE/melt-runtime.h $MELT_PLUGIN_SOURCE/melt-runtime.c
I just tried, and it seems to me that the generated code is fairly
portable, since it references existing GCC GTY-ed types by routine
names, like e.g. gt_ggc_m_9tree_node etc. So I guess that if some
field is target specific inside e.g. tree-s, the routine name won't
change.
While I do understand the requirement (and its current reason) that in
plugin mode, gengtype needs the entire build tree of the GCC for which
we are building a plugin, I also understand that distribution makers
are not happy of that requirement.
We cannot remove that heavy requirement for 4.5 (because 4.5 is in
stage 4, and because it is not easy to do). However, we might think of
enhancing gengtype for 4.6.
A possible way of doing that enhancement might perhaps be that
1. (in ordinary non plugin mode, within a plugin-enabled GCC) gengtype
not only generates all the necessary gt*.h files, but also generate an
easy-to-parse textual representation (perhaps in JSON or XML or Lispy
syntax) of all the data it has processed (that is of all the GTY-ed
data descriptors). Let imagine that file will be
gcc-gty-data-descr.json
2. The installation procedure installs the gengtype binary and the
above mentioned gcc-gty-data-descr.json appropriately (probably under
`gcc-trunk -print-file-name=plugin`/etc/ ...)
3. The installed gengtype (which in my opinion should better be called
& invoked as gcc-gengtype) read data from the installed
gcc-gty-data-descr.json
Again, this is food for thought only. Comments are welcome! We sadly
cannot make that for gcc 4.5! So for gcc-4.5 building plugins which do
use PLUGIN_REGISTER_GGC_ROOTS is terrible for distribution makers
(like Debian); they have to *keep* the *build* tree of their GCC which
seems to be against the spirit of packaging systems in most Linux
distribution.
A tedious alternative might be e.g. for debian to figure out all the
files needed to gengtype and to package all of them (including a
normalized gtyp-input.list and all the files listed there and the
gengtype executable) in their gcc-4.5-plugin-dev package.
I am very sadly perhaps considering to store, e.g. in
contrib/generated-gt-melt-runtime-for-plugins.h the generated
gt-melt-runtime.h for MELT as plugin. Storing in a source depository a
generated file has to be done with caution, and storing a generated
file which needs to be "manually" regenerated is sad & ugly.
Since this message (a reply on gcc@gcc.gnu.org to the
http://gcc.gnu.org/ml/gcc/2010-03/msg00124.html message) could be of
interest to debian-...@lists.debian.org I am also BCC-ing it to them.
Regards.
--
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 mines, sont seulement les miennes} ***
gcc-4.5-20100311 is now available
Snapshot gcc-4.5-20100311 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100311/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 157393 You'll find: gcc-4.5-20100311.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100311.tar.bz2 C front end and core compiler gcc-ada-4.5-20100311.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100311.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100311.tar.bz2 C++ front end and runtime gcc-java-4.5-20100311.tar.bz2 Java front end and runtime gcc-objc-4.5-20100311.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100311.tar.bz2The GCC testsuite Diffs from 4.5-20100304 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?
> 1. (in ordinary non plugin mode, within a plugin-enabled GCC) gengtype > not only generates all the necessary gt*.h files, but also generate an > easy-to-parse textual representation (perhaps in JSON or XML or Lispy > syntax) of all the data it has processed (that is of all the GTY-ed > data descriptors). Let imagine that file will be > gcc-gty-data-descr.json You might want to look at the gengtype debugging dump support on gc-improv branch, which I will submit shortly for 4.6 trunk. -- Laurynas
Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?
Laurynas Biveinis wrote:
1. (in ordinary non plugin mode, within a plugin-enabled GCC) gengtype
not only generates all the necessary gt*.h files, but also generate an
easy-to-parse textual representation (perhaps in JSON or XML or Lispy
syntax) of all the data it has processed (that is of all the GTY-ed
data descriptors). Let imagine that file will be
gcc-gty-data-descr.json
You might want to look at the gengtype debugging dump support on
gc-improv branch, which I will submit shortly for 4.6 trunk.
Thanks! Yes, I looked at your gengtype.c in your branch, and it is the
kind of code I was dreaming of.
Usually, in persistency machinery, the code to reload data from the
file is a bit more complex than the code to dump it. Do you have any ideas?
And more significantly, do you think that my idea of persisting GTY-ed
data descriptors in gengtype is good enough to have: tools (gengtype) &
data (e.g. hypothetical gcc-gty-data-descr.json) installed in the GCC
installation, and reused by gengtype invocation for plugins, so to
remove the harsh constraint of keeping both source & build tree? Or did
I forgot something?
Also, what is a summary of the GTY & gengtype improvements (w.r.t
plugins) in your gc-improv branch?
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 mines, sont seulement les miennes} ***
