Re: Merging the cxx-conversion branch into trunk
On Thu, Aug 2, 2012 at 8:58 PM, Diego Novillo wrote:
>
> We are about ready to have the cxx-conversion branch merged back into trunk.
>
> This merge will change the following:
>
> 1- The compiler can only be built with a C++ compiler.
>
> 2- The tree macros can be called from gdb (when GCC is built with -g3).
>
> 3- htab and VEC have been converted to use C++ templates. The existing API
> is still present as wrappers that call the new API. We will change this
> after the branch is merged.
>
> 4- gengtype is now capable of supporting user-defined structure markers.
> This allows users to have structures in GC memory for which gengtype does
> not know how to generate marking code for.
>
> I am currently debugging this change. After I fix the remaining PCH
> failures, I will send the patch for review.
Please make sure to send a patch doing 4. for review separate of the cxx-branch
merging.
> Our immediate plan after we merge the branch into trunk includes:
>
> - Fix any failures caused by the change.
> - Modifying all the user code for VEC and htab to use the new interfaces.
> - Convert double_int.
> - Convert cgraph.
> - Convert the pass manager.
> - Convert hooks.
>
> After this round of changes, we are planning to work on more API cleanups
> (e.g., adding the introspection API that would be usable for plugins as we
> discussed in the Plugins BoF in Prague).
Micha worked on the plugin API for some time and I believe has something
ready already (also introspection only).
> I would also like to reduce the amount of code that is being generated by
> gengtype. There is a lot of boilerplate code that could be offloaded to
> user-provided functions. This would reduce the number of GTY markings that
> we need to support. There are other aspects of this that I will include in
> the gengtype patch that I'm finishing up.
Sure, I expect that most of the special GTY annotations should be handled
by user-provided walkers. I suppose it would be useful to allow to specify
that only certain fields of a struct are handled by the user walker? Like
/* Base of all entries in the symbol table.
The symtab_node is inherited by cgraph and varpol nodes. */
struct GTY(()) symtab_node_base
{
...
/* Linked list of symbol table entries starting with symtab_nodes. */
symtab_node next GTY((specialized));
symtab_node previous GTY((specialized));
...
and then have gengtype generate
mark (symtab_node_base *base)
{
... stuff ...
mark_special (base);
}
?
Richard.
> We will keep the branch alive to work on bigger scale changes that will not
> be ready for this release (e.g., experimenting with gimple and tree).
>
> I will split up the merge patch in 4 or 5 chunks to simplify reviews. For
> now, we would appreciate if folks test the branch with:
>
> $ svn co ssh://gcc.gnu.org/svn/gcc/branches/cxx-conversion
> $ mkdir bld && cd bld
> $ ../cxx-conversion/configure --enable-languages=all,ada,go && make
> bootstrap && make check
>
> We welcome any suggestions (and volunteers!)
>
>
> Thanks.
Bug for each patch
Hi, Can someone please clarify some policies with GCC contribution. If I have a patch with a GCC enhancement, do I need to obtain a bug report for it and then submit the patch or I can submit a patch to the patch mailing list without opening a bug report? Cheers, -- PMatos
Re: Bug for each patch
On Fri, Aug 3, 2012 at 6:33 AM, Paulo J. Matos wrote: > > Can someone please clarify some policies with GCC contribution. If I have a > patch with a GCC enhancement, do I need to obtain a bug report for it and > then submit the patch or I can submit a patch to the patch mailing list > without opening a bug report? You can submit a patch to the gcc-patches list without opening a bug report. Ian
MELT plugin release 0.9.6-d for GCC 4.6 and 4.7 (& graphical probe)]
Hello All, After many tentative releases, I am proud to announce the MELT plugin 0.9.6-d release for GCC 4.6 and 4.7 MELT is a high-level domain specific language to extend GCC (with features like pattern matching to make that less difficult than thru GCC plugins hand-coded in C). You can download the gnuzipped tar source of MELT from http://gcc-melt.org/melt-0.9.6-d-plugin-for-gcc-4.6-or-4.7.tar.gz It is a gnu zipped source tar file of 5580021 bytes & md5sum 83ac70197a57968ed732d0f5442a3c2b extracted i from the MELT branch of GCC svn revision 190124 on August 03rd 2012. This MELT plugin release brings a feature which could interest every person curious about GCC internal representations (Gimple & Tree-s), even those not interested by the MELT domain specific language: the so called graphical probe. A screen shot is available on http://gcc-melt.org/ and you can get it directly from http://gcc-melt.org/melt-0.9.6d-probe-august-2012.png It shows you MELT and its probe in action when compiling the tree-ssanames.c file of GCC. On the left, two informational dialog windows show the GCC internal representation tied to a particular source location. On the right of the screen, the compiled source code is shown (with a tab for each source file). For each location interesting to GCC, a button (quite ugly) is given inside the source code, and you can push it to get informational dialog windows giving the GCC internal representation for that particular location. In a sense, this is probe dual to the GCC dump files, which show you all the internal representation after some given pass. The probe is coded in C++ using GtkMM for GTK 3.4 (you need at least that 3.4 version of Gtk, older Gtk versions have a naughty bug affecting the behavior of the probe). The probe inside MELT is sometimes buggy (on the GTK side); on some occasion, the GTK probe is looping (probably my misunderstanding of GTK, or maybe a GTK bug). I compile the probe with g++ -Wall -O -g $(pkg-config --cflags --libs gtksourceviewmm-3.0 gtkmm-3.0 gtk+-3.0) \ -o $HOME/bin/simplemelt-gtkmm-probe simplemelt-gtkmm-probe.cc and I added in my path a tiny shell script named "melt-probe" which has just #!/bin/sh exec simplemelt-gtkmm-probe -T $* # eof melt-probe script The -T argument to simplemelt-gtkmm-probe shows the trace window explaining the textual exchanges between MELT plugin and the probe binary. You can remove that argument if you want. The probe works thru a special mode of MELT. Once you have installed MELT (and manually installed the probe with melt-probe script), you can run gcc -fplugin=melt -fplugin-arg-melt-mode=probe -c yourfile.c (with of course other options, e.g. -O or -I...). The probe uses MELT functional abilities (closures are used to implement it), and the fact that MELT is compiled to C (textual requests coming from the probe gives a SIGIO, which is tested in a lot of places in the MELT generated C code). Now, some more specific MELT changes: NEWS for 0.9.6-d MELT plugin for GCC 4.6 & 4.7 [[august, 03rd 2012]] Language improvements = Syntax: (USE-PACKAGE-FROM-PKG-CONFIG ) On systems, such as most Linux distributions, with the pkg-config utility http://en.wikipedia.org/wiki/Pkg-config http://pkg-config.freedesktop.org/ the given packagename is used when compiline the generated C code and when linking the generated shared module. Emited C code by MELT is more conformant to C++ and C coding standards. More primitives, macros, ... notably WHEN & UNLESS, like in Common Lisp... The CLASS_CONTAINER has been renamed as CLASS_REFERENCE. Likewise SET_CONTENT is renamed as SET_REFERENCE... Runtime improvements When a function is called in an occurrence expecting secondary results and does not return secondary results, a warning is emitted. MELT may emit symlinks to "unique" C files in the workdir, helpful when regenerating an already generated file... "Interrupts" have been inproperly named, speak of "signals" (in the Posix/Unix sense, not the Gtk/Qt one!). The build of the MELT runtime and of the MELT modules is done by an autogen-erated shell script melt-build-script.sh generated from melt-build-script.tpl & melt-build-script.def. It should be more robust, and avoid doing useless things, so is faster when you rebuild again MELT. Add support for timers & child processes... Debugging run works well with plugin using -fplugin-arg-melt-debugging=all (or =mode). Library improvment == The probe mode is able to to start and communicate an external graphical probe. A simple probe, coded in C++ for GTKmm3.4, is available as a self contained program simplemelt-gtkmm-probe.cc; its compilation command is given at the very end of that sourc
Re: Change default BOOT_CFLAGS for release builds
Hello, I got no replies, so I guess there is no will to move GCC to -O3 by default, so I shouldn't bother submitting a patch? As a reminder, cc1 is 0-4% faster but almost 10% bigger executable. Testsuite showed no regression. Bootstrap time is greater (don't have the numbers) but I proposed adding and documenting a "make release" target that would be used by distros, while default target would remain -O2 (or even -O1) so that our test builds complete in sensible time. In the future we could also turn on other stable ways to speed up GCC for release builds (e.g. lto/profiledbootstrap). Thanks, Dimitris On Wed, 11 Jul 2012, Dimitrios Apostolou wrote: Hello list, we discussed the subject in the BOF but I didn't quite get what the consensus is, so that I can start changing things. What I have in mind is to introduce and document a new "make release" target that builds GCC in the fastest /stable/ way possible, for example --enable-checking=release BOOT_CFLAGS=-O3. I don't know what are the exact options we want, personally I tried -O3 and cc1 was 0% - 4% with no regressions, so IMHO we definitely want -O3 as default. I'm curious also about lto and profiledbootstrap but don't know if they should be default, in any case if anything gets worse we can revert. The actual purpose of adding a separate "release" target and documenting it properly is for all distributors (besides the ones having specific constraints, like embedded) to actually build GCC in the best way possible. Since we will be making sure no problems are introduced with -O3/lto/whatever this will also be a great way to advertise that these build methods actually work well, and it's an advantage over other compilers. Finally, that way the default target can remain -O2 (or even -O1) so that all our test bootstraps complete in sensible time. So, what do you think? Thanks, Dimitris P.S. Size change for stripped cc1 is almost 10% between -O2 and -O3: $ wc -c cc1* 10858100 cc1.O2 12103284 cc1.O3
Re: Are we fast yet?
Hello, I've finished some final updates, according to recommendations you proposed. Please let me know what you think. On Wed, 4 Jul 2012, Dimitrios Apostolou wrote: On Thu, 28 Jun 2012, Dimitrios Apostolou wrote: http://teras-ics.mooo.com:8003/ * 4 tests are now benchmarked: empty.c, reload.c with -g3 -O0, reload.c with -g -O2, XPath.cpp with -g -O2 from xalanc (someone mentioned xalanc benchmark of SPEC2006 as good way to stress cc1plus, unfortunately I couldn't find SPEC source so I used one of the most complex files of xalanc). * Instruction count on the left, time on the right. * All points on the first graph are clickable so you can view the callgraph and click through it to the function you are interested. You can also edit directly the URL to achieve this, e.g. by adding &f=df_install_refs to load that function. * Memory usage is on the second graph Thanks, Dimitris P.S. I'll refrain from doing any more web development until the end of GSOC, but all my cron jobs are running regularly so this content is being updated automatically. Next step on this front is to actually bring this online at gcc.gnu.org, I'll contact overse...@gcc.gnu.org for this.
Re: Merging the cxx-conversion branch into trunk
On 8/3/12, Richard Guenther wrote:
> On Aug 2, 2012 Diego Novillo wrote:
> > We are about ready to have the cxx-conversion branch merged
> > back into trunk.
> >
> > This merge will change the following:
> >
> > 1- The compiler can only be built with a C++ compiler.
> >
> > 2- The tree macros can be called from gdb (when GCC is built
> > with -g3).
> >
> > 3- htab and VEC have been converted to use C++ templates. The
> > existing API is still present as wrappers that call the new
> > API. We will change this after the branch is merged.
> >
> > 4- gengtype is now capable of supporting user-defined structure
> > markers. This allows users to have structures in GC memory for
> > which gengtype does not know how to generate marking code for.
> >
> > I am currently debugging this change. After I fix the remaining
> > PCH failures, I will send the patch for review.
>
> Please make sure to send a patch doing 4. for review separate of
> the cxx-branch merging.
>
> > Our immediate plan after we merge the branch into trunk includes:
> >
> > - Fix any failures caused by the change.
> > - Modifying all the user code for VEC and htab to use the
> > new interfaces.
> > - Convert double_int.
> > - Convert cgraph.
> > - Convert the pass manager.
> > - Convert hooks.
> >
> > After this round of changes, we are planning to work on more
> > API cleanups (e.g., adding the introspection API that would be
> > usable for plugins as we discussed in the Plugins BoF in Prague).
>
> Micha worked on the plugin API for some time and I believe has
> something ready already (also introspection only).
>
> > I would also like to reduce the amount of code that is being
> > generated by gengtype. There is a lot of boilerplate code that
> > could be offloaded to user-provided functions. This would reduce
> > the number of GTY markings that we need to support. There are
> > other aspects of this that I will include in the gengtype patch
> > that I'm finishing up.
>
> Sure, I expect that most of the special GTY annotations should be
> handled by user-provided walkers. I suppose it would be useful
> to allow to specify that only certain fields of a struct are
> handled by the user walker? Like
>
> /* Base of all entries in the symbol table.
> > The symtab_node is inherited by cgraph and varpol nodes. */
> struct GTY(()) symtab_node_base
> {
> ...
> /* Linked list of symbol table entries starting with symtab_nodes. */
> symtab_node next GTY((specialized));
> symtab_node previous GTY((specialized));
> ...
>
> and then have gengtype generate
>
> mark (symtab_node_base *base)
> {
> ... stuff ...
> mark_special (base);
> }
>
> ?
The intent was that, for example, the author of a template class
Foo would write a template function mark(Foo&) that called
mark on each of the relevant fields. The overloading and the rest
of gengtype-generated code would do the right thing.
> > We will keep the branch alive to work on bigger scale changes
> > that will not be ready for this release (e.g., experimenting
> > with gimple and tree).
> >
> > I will split up the merge patch in 4 or 5 chunks to simplify
> > reviews. For now, we would appreciate if folks test the branch
> > with:
> >
> > $ svn co ssh://gcc.gnu.org/svn/gcc/branches/cxx-conversion
> > $ mkdir bld && cd bld
> > $ ../cxx-conversion/configure --enable-languages=all,ada,go && make
> > bootstrap && make check
> >
> > We welcome any suggestions (and volunteers!)
--
Lawrence Crowl
Re: TOC errors on AIX
On Jul 31, 2012, at 4:30 PM, David Edelsohn wrote: > On Sun, Jul 29, 2012 at 12:48 PM, Perry Smith wrote: >> Hi, >> >> This is an age old topic but I can't find how to solve it. I've searched >> the past few days. >> >> I'm trying to build passenger on AIX 6.1 TL07 SP03 using gcc 4.5.2 that I >> built myself. I've used it for a number of months and have built many >> things. >> >> The short question is how do I get rid of these warnings? >> >>> ld: 0711-768 WARNING: Object >>> ext/apache2/module_libboost_oxt.a[system_calls.o], section 1, function >>> .accept: >>>The branch at address 0x2ac0 is not followed by a recognized no-op >>>or TOC-reload instruction. The unrecognized instruction is >>> 0x7C601B78. >> >> The link has many errors like this. For whatever reason, passenger builds >> the same file two different ways and puts them in two different places. >> Upon closer examination the file that the link is complaining about does in >> fact have bad code. >> >> The bad compile line is: >> >>> g++ -Iext -fPIC -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED >>> -U__STR__ -D_THREAD_SAFE -D_LARGEFILE64_SOURCE >>> -I/gsa/ausgsa/projects/r/ruby/apache2/include/apr-1 >>> -I/gsa/ausgsa/projects/r/ruby/apache2/include/apr-1 >>> -I/gsa/ausgsa/projects/r/ruby/apache2/include -D_REENTRANT >>> -I/usr/local/include -DHASH_NAMESPACE="__gnu_cxx" >>> -DHASH_NAMESPACE="__gnu_cxx" -DHASH_FUN_H="" >>> -DOXT_DISABLE_BACKTRACES -DHAS_ALLOCA_H -Wall -Wextra -Wno-unused-parameter >>> -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long >>> -Wno-missing-field-initializers -g -DPASSENGER_DEBUG >>> -DBOOST_DISABLE_ASSERTS -o >>> ext/apache2/module_libboost_oxt/oxt/system_calls.o -c >>> ext/oxt/system_calls.cpp >> >> and produces: >> >>> ... >>> lwz 5,128(31) >>>bl .accept >>>mr 0,3 >>> ... >> >> There needs to be a nop after the bl so the linker / loader can stuff in an >> instruction to restore the toc. >> >> There are many warnings for this compile as well about the visibility. e.g. >> >>> ext/oxt/system_calls.cpp: In function 'int oxt::syscalls::accept(int, >>> sockaddr*, socklen_t*)': >>> ext/oxt/system_calls.cpp:209:1: warning: visibility attribute not supported >>> in this configuration; ignored >> >> >> The compile line that is good is: >> >>> g++ -Iext -D_REENTRANT -I/usr/local/include -DHASH_NAMESPACE="__gnu_cxx" >>> -DHASH_NAMESPACE="__gnu_cxx" -DHASH_FUN_H="" >>> -DOXT_DISABLE_BACKTRACES -DHAS_ALLOCA_H -Wall -Wextra -Wno-unused-parameter >>> -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long >>> -Wno-missing-field-initializers -g -DPASSENGER_DEBUG >>> -DBOOST_DISABLE_ASSERTS -o ext/common/libboost_oxt/oxt/system_calls.o -c >>> ext/oxt/system_calls.cpp >> >> which produces good code: >> >>> ... >>>lwz 5,128(31) >>>bl .accept >>>nop >>>mr 0,3 >>> ... >> >> The good compile has no warnings. >> >> I figure it is the -fvisibility that is getting me into trouble but I am not >> sure if it is safe to just get rid of it. There are also macros in the >> boost *.hpp files that muck with the visibility setting. >> >> The link line is (if needed): >> >>> g++ -shared ext/apache2/Configuration.o ext/apache2/Bucket.o >>> ext/apache2/Hooks.o ext/apache2/mod_passenger.o -fPIC -o >>> ext/apache2/mod_passenger.so -fPIC -fvisibility=hidden >>> -DVISIBILITY_ATTRIBUTE_SUPPORTED -U__STR__ -D_THREAD_SAFE >>> -D_LARGEFILE64_SOURCE -I/gsa/ausgsa/projects/r/ruby/apache2/include/apr-1 >>> -I/gsa/ausgsa/projects/r/ruby/apache2/include/apr-1 >>> -I/gsa/ausgsa/projects/r/ruby/apache2/include -D_REENTRANT >>> -I/usr/local/include -DHASH_NAMESPACE="__gnu_cxx" >>> -DHASH_NAMESPACE="__gnu_cxx" -DHASH_FUN_H="" >>> -DOXT_DISABLE_BACKTRACES -DHAS_ALLOCA_H -Wall -Wextra -Wno-unused-parameter >>> -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long >>> -Wno-missing-field-initializers -g -DPASSENGER_DEBUG >>> -DBOOST_DISABLE_ASSERTS ext/apache2/module_libpassenger_common.a >>> ext/apache2/module_libboost_oxt.a -fPIC >>> -L/gsa/ausgsa/projects/r/ruby/apache2/lib -lapr-1 -Wl,-G -Wl,-brtl >>> -L/gsa/ausgsa/projects/r/ruby/apache2/lib -laprutil-1 -lpthread > > The problem most likely is -fvisibility. AIX does not support > visibility the way that GNU/Linux does, although GNU/Linux is evolving > toward the symbol visibility model that AIX had all along. > > Two questions are: > > 1) Why does the package think that AIX supports visibility and using > those options? I tracked this down. They ask "does the compiler support it?" (which gcc does) and so they assume the platform does. I changed the test to just return false on AIX. That got rid of the -fvisibility flag, 99% of my compile warnings as well as the link warnings. > > 2) Why is the package linking with -Wl,-G -Wl,-brtl? I've never 100% understood all this and so the package probably doesn't either. But -G impli
gcc-4.6-20120803 is now available
Snapshot gcc-4.6-20120803 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120803/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 190135 You'll find: gcc-4.6-20120803.tar.bz2 Complete GCC MD5=7b848eab0803ee5734ff78b87e9ccb7e SHA1=bfa31ea529cf3f72ca3eb0ee2bfc7f11b47140ab Diffs from 4.6-20120727 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
Creating a global string constant node.
Hello, I need to create a global string constant node. In the past, I have always been able to add global variables, but I have always left them uninitialized. I know the trick is to build_decl() of VAR_DECL and, I guess in this case the type char_node_type. However, I want the global decl initialized and referring to a string literal. I know of build_string_literal() but that does not create a decl node that I am aware of. I am unsure as to how to set that literal to my VAR_DECL instance, so that it is in the read-only section of the resulting binary, and referred to by the identifier I pass to build_decl(). Is there an example in the code my grep-foo has failed me for this specific case? Thanks much! -Matt
Re: Creating a global string constant node.
On Sat, Aug 4, 2012 at 12:52 PM, Matt Davis wrote: > Hello, > I need to create a global string constant node. In the past, I have > always been able to add global variables, but I have always left them > uninitialized. I know the trick is to build_decl() of VAR_DECL and, I > guess in this case the type char_node_type. However, I want the > global decl initialized and referring to a string literal. I know of > build_string_literal() but that does not create a decl node that I am > aware of. I am unsure as to how to set that literal to my VAR_DECL > instance, so that it is in the read-only section of the resulting > binary, and referred to by the identifier I pass to build_decl(). Is > there an example in the code my grep-foo has failed me for this > specific case? After a bunch of tries, I have what I need. I knew probability would pay off, some call this persistence, I call it probability. Anyways, I had to set DECL_INITIAL for the VAR_DECL I created. I set the decl with the string literal from build_string_literal(). I then called varpool_finalize_decl() on the decl instance and also marked the node as "needed" via varpool_mark_needed_node(). -Matt
