Wiki, documenting Tree SSA passes
Dear All, I am still a newbie on GCC! On the Wiki, http://gcc.gnu.org/wiki/MiddleEnd I am trying to document very briefly the passes on Gimple SSA trees I do know about the chapter 8.4 (Tree SSA passes) of the GCC internal documentation (but some of the passes are not listed there) I cannot yet submit patches to it (file gcc/doc/passes.texi) yet, because my copyright assignement form takes some time to be signed at CEA-LIST where I am working on GCC (but I think it will be signed soon). Do I understand correctly that no patch of more than 10 lines can be sent to gcc-patches@ without the FSF having recieved the copyright transfer (or assignment) paper? Is documenting the passes on the Wiki worthwile? Could some people document (in a few sentences) each pass (ie each struct tree_opt_pass defined in the source tree) if possible? Thanks for reading (and sorry for the trivial questions above) -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Q: whole program entry point in SSA?
Hello, (I'm still a newbie in gcc) I am interested in -fwhole-program analysis (flag_whole_program) and I know that with -O3 -fwhole-program the cgraph_nodes is cleaned (in cgraphunit.c probably by cgraph_varpool_remove_unreferenced_decls) so that only functions callable from main are kept (as a counter example, compile with -fwhole-program -O3 a test.c file without any main function, you'll get a nearly empty test.s without any code; I even submitted a trivial patch http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00626.html to gcc-patches@ adding a warning in that case) But I do not understand exactly where in the GCC source code the main entry point is used as a starting point for this call graph analysis. I guess that it is in the decide_is_function_needed function of cgraphunit.c (with a MAIN_NAME_P test). Could someone confirm my partial understanding please? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
generation of gt-*.h files
Dear All, I'm still a newbie, and do not understand very well the machinery behind the GCC garbage collector, in particular the following behavior on a recently svn update-ed GCC trunk. My system is an AMD64/Debian/Sid cd /usr/src/Lang/gcc # my trunk svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 117825 Node Kind: directory Schedule: normal Last Changed Author: bkoz Last Changed Rev: 117825 Last Changed Date: 2006-10-17 14:53:40 +0200 (Tue, 17 Oct 2006) mkdir ../_GccObj cd ../_GccObj /usr/src/Lang/gcc/configure --disable-multilib --enable-languages=c,c++ make -j4 ## lots of output, compilation is successful ls -l gcc/xgcc -rwxr-xr-x 1 basile src 539143 Oct 17 15:51 gcc/xgcc ls -l gcc/gt-tree-ssa-operands.h -rw-r--r-- 1 basile src 1086 Oct 17 15:49 gcc/gt-tree-ssa-operands.h mv gcc/gt-tree-ssa-operands.h /tmp ## I removed a generated header (for GC support within GCC) ### make[2]: Entering directory `/usr/src/Lang/_TrunkGccObj/gcc' gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/usr/src/Lang/gcc/gcc -I/usr/src/Lang/gcc/gcc/. -I/usr/src/Lang/gcc/gcc/../include -I/usr/src/Lang/gcc/gcc/../libcpp/include -I/usr/src/Lang/gcc/gcc/../libdecnumber -I../libdecnumber /usr/src/Lang/gcc/gcc/tree-ssa-operands.c -o tree-ssa-operands.o /usr/src/Lang/gcc/gcc/tree-ssa-operands.c:2571:34: error: gt-tree-ssa-operands.h: No such file or directory Why is the gt-tree-ssa-operands.h not rebuilt if removed? More generally, I have trouble adding a pass basile-analys.c (which does nothing useful yet) which includes its header basile-analys.h which contains struct-ures with GTY(()) so I need to have gt-basile-analys.h generated from basile-analys.h If you really want to dive into my sources (nothing interesting yet, I'm still earning Gcc with some pain), you could get them from http://ours.starynkevitch.net/basile/ggcc-basile.tgz (but this is a home computer on ADSL) - this is an archive of all the source files I added or changed to the GCC trunk Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
GTY(()) & GCC garbage collector
Dear All, I finally solved (with help from Sebastian Pop) my problems about GTY(()) etc... I added some blurb on it in the Wiki http://gcc.gnu.org/wiki/Memory_management Please correct if I am wrong Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
fwhole-program, -combine, several C sources ?
Dear All, For C source programs only, is there a scenario where several (eg two or more) C source files (ie passed *.c arguments) can be passed with the -fwhole-program flag and without the -combine flag? In other words, some medium sized (eg < 100 KLOC of C source in several *.c files) programs can be compiled with gcc -O3 -fwhole-program -combine *.c -o prog ...libraries and includes but the compilation fails if the -combine flag is not given. Maybe the driver might issue some warning if -fwhole-program is given without -combine for several C source inputs? Or probably, I am not very well understanding the -fwhole-program flag By the way, I am surprised that so few programs are compiled with it... http://www.google.com/codesearch?q=fwhole-program give few results Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
wiki topics wish (configuration related)
Dear All If this is annopropriate here, please accept my apologies There are several topics that I wish to be covered a bit on the Wiki (or some other documentations), mostly related to configuration (and autoconf, with which I am not very familiar, especially in the context of GCC whose configuration is quite complex). 0. I am not sure to understand exactly the steps (and commands to run) when touching to a configure.ac file... I made an educated guess which happens to work most of the time. (In particular it seems that autconf2.60 works even if 2.59 is required) 1. How to add a pass on Gimple/SSA (this is something I know how) which can be disabled at GCC configuration time, ie add a pass in a source tree-FOO.c (and of course in passes.c) which can be disabled by a --disable-FOO configure switch? When enabled, the pass adds a new -fdo-FOO flag (which should be absent if disabled) at the newly built gcc & cc1 runtime. 2. How to add an external library (I actually am thinking of mysqlclient or gdbm or dl -for dlopen- and probably the Parma Polyhedral library) which can be disabled by such a --disable-FOO configure switch, and which, when enabled at configure with --enable-FOO, is actually checked for (in particular, availability of header files, test of minimal features); When enabled I want these new libraries to be linked into the newly built cc1 and gcc. PS. I'm just beginning to work on adding more global static analysis passes into GCC. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
submitting patches before copyright assignment fully done?
Dear All, My copyright assignment is not yet signed, but I am pretty confident that it will be signed (hopefully soon, and surely in 2006 ie before Christmas). Can I submit patches (to gcc-patches@) which are not trivial (ie more than 10 lines of code), or should I wait till the copyriight assigment has been recieved by the FSF (signed by my employing organisation and by FSF? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
[ANNOUNCE] GlobalGCC [GGCC] project (within ITEA programme)
Dear All, My collegues from the GGCC consortium have asked me to send the following announcement to this GCC mailing list. Please reply to [EMAIL PROTECTED], [EMAIL PROTECTED] for any remarks and questions regarding GGCC ANNOUNCEMENT for the launch of the GlobalGCC [GGCC] project within the ITEA [Information Technology for European Advancement] programme GENERAL INFORMATION In September 2006, a 15-partners consortium has started to work on the GlobalGCC [GGCC] project, within the ITEA [Information Technology for European Advancement] programme (see http://www.itea2.org/). The GGCC project will last 30 months and is partly funded (around 30%-40%) by French, Spanish and Swedish public authorities. The partnership is composed of various types of entities (Small and Medium sized Enterprises (SMEs) +, big corporations ++, research labs and universities *) that are listed hereafter in alphabetical order per country: in France: Airbus/France (++), Bertin (+), CEA-LIST (*), INRIA-Futurs (*), Mandriva (+) in Spain: Aquiline (+), Answare (+), Base (+), IDI Eikon (+), SQS (+), Telefonica I+D (++), UPM (*) in Sweden: MySQL A.B (+), SICS (*), Syxoo (+) The project leader is Mandriva (the company behind the Mandriva ex-Mandrakesoft Linux distribution in France). OBJECTIVES OF THE PROJECT The GGCC (ITEA) project aims to extend the free GNU Compiler Collection by globally processing several compilation units (e.g. work on a whole program or on a library) in order to customize and configure GCC to European software industry needs : for performance level or for better diagnosis. The GGCC (ITEA) contribution will be GPL licenced free software, and will be proposed to the FSF. The GGCC (ITEA) consortium is determined to work in close cooperation with the GCC community and the FSF. In an effort to empower the mainline GCC4 compiler from FSF (which focuses on code generation quality and compilation speed) with advanced compile-time techniques, the GGCC (ITEA) project aims at integrating into a GCC4 branch sophisticated program-wide compile-time analyses. As a result of that, it is expected that GGCC be more resource consuming (e.g., it could run 10 times slower than the GCC4 compiler). In return for that speed loss, more program bugs are expected to be pinpointed, and programmers will be able to state properties to be met in their code. Additionally, all the good characteristics of GGCC (high-quality code, number of available back-ends, etc.) are expected to be kept. The GGCC (ITEA) product will be hosted on Unix/Posix/GNU/Linux environments. The GGCC (ITEA) project aims to extend GCC through continuing research efforts, providing tools, interfaces and documentation which will enable new approaches to be developed around program-wide static analysis techniques. The static analysis of GGCC (ITEA) will work on the GIMPLE internal representations of GCC, hence be usable for all the current source languages and target systems available today in GCC. The static analysis techniques projected for GGCC (ITEA) will be means permitting: 1. Global program-wide optimisation (because the properties inferred at a given call site may be propagated to avoid useless computations in the program; for example if on a given call site and calling context the static analyser determined that a pointer is not null, pointing to a local variable which is positive, this information can be used to optimise further on, etc...). 2. Hazard detections, that are warnings (for the developer using GGCC (ITEA) compiler) about possible threats like: if a function f() was called by g() called by h(x) with x>0 then at line 345 of foo.c there is a possible zero-divide fault. The challenge is to reduce the number of false positive alarms (which are stricto sensu unavoidable). 3. Coding rule validation: A formalism will be defined by the GGCC consortium to express coding rules, and to use static analysis techniques to validate some of them. To permit development of static analysis techniques, some work on the GCC infrastructure (in particular, persistency of GIMPLE internal representation and extensions of it) is required. CONTACT DETAILS The main contact person is Arnaud Laprévote who can be contacted at the following e-mail address: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> The GGCC web site is: www.ggcc.info (will be operational very soon) Comments and remarks are welcome and can be sent to the following e-mail address: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> NB: all my other emails to this or other lists are only mine, and my own work on GCC is partly funded by this GGCC project (ITEA labelled) -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases:
Re: wiki topics wish (configuration related)
on Sat, Oct 28, 2006 at 11:53:29PM +0200, I (Basile S.) asked > There are several topics that I wish to be covered a bit on the Wiki (or > some other documentations), mostly related to configuration (and autoconf, > with which I am not very familiar, especially in the context of GCC whose > configuration is quite complex). I digged up a little bit this subject, and I wrote a very incomplete wiki page on it. http://gcc.gnu.org/wiki/AboutGCCConfiguration I borrowed a few sentences elsewhere, in particular from the autobook http://sources.redhat.com/autobook/ by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor (I sent a small email to Gary about this). Comments and improvements are welcome. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8601 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Re: Threading the compiler
Le Fri, Nov 10, 2006 at 01:33:42PM -0800, Sohail Somani écrivait/wrote: > I don't think it can possibly hurt as long as people follow normal C++ > coding rules. > > The main issue is not really language choice though. The main issues > would likely be defining data to be isolated enough to be useful to do > work in parallel. I see the following issues first (once parsing is done) we could (at least in non-inter-procedural phases & passes, which might be common, in particular in -O1 or maybe -O2) handle in parallel different functions inside a C compilation unit. Another trick (particularily in LTO) could be to store persistently some internal representation for each function (within a compilation unit) and to recall it if the compiler notice that a given function did'nt change. However, for multi-threading the compiler, a significant issue might be the internal GCC garbage collector (I'm not sure it is easily multi-threadable). I'm not familiar enough with actual gcc timing to be sure all this would really speedup compilation time. I'm not pretending to volunteer the multi-threading effort, because I am not yet familiar enough with GCC internals My 0.02 euros! Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Re: GCC Garbage Collection
Le Mon, Nov 13, 2006 at 06:47:40AM +, Brendon Costa écrivait/wrote: > Hi All, > >I think i am having trouble with the garbage collector deleting the > memory for tree nodes that i am still using. The wiki page http://gcc.gnu.org/wiki/Memory_management might help you I had a quick glance at your mail, so I may be wrong, but I am not sure that you configured correctly the build system so that thet GTY(()) macros get processed correctly. Sadly, the gengtype generator does not recieve the list of files to process thru the command line, but only in internal data. Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Re: wiki topics wish (configuration related)
Le Tue, Nov 07, 2006 at 11:19:16PM +0100, basile écrivait/wrote: > on Sat, Oct 28, 2006 at 11:53:29PM +0200, I (Basile S.) asked > > > There are several topics that I wish to be covered a bit on the Wiki (or > > some other documentations), mostly related to configuration (and autoconf, > > with which I am not very familiar, especially in the context of GCC whose > > configuration is quite complex). > > I digged up a little bit this subject, and I wrote a very incomplete wiki > page on it. > > http://gcc.gnu.org/wiki/AboutGCCConfiguration Please review (and contribute or correct) the above wiki page! I added there (with the help of Sebastian Pop) a detailed description about how to add a new library in the Wiki page. It would be nice if someone could review it. I actually believe it should go (with corrections & enhancements) into the official GCC internal documentation, but I cannot yet submit official patches (into gcc/doc/) because my copyright assignment is not yet signed. I hope to have it signed before Christmas 2006, and possibly before end of november 2006. (A big thanks to Jonas Jacobson from the FSF for his patience, and to internal collegues at CEA). I really think that some GCC documentation should be helpful for GCC newbies (ie new hackers like me), and not only for GCC users (those compiling GCC, and/or using GCC to compile their stuff)... BTW, I find that having the copyright assignment in big organisations is a exhausting and painful work (internal lobbying, more than a full time month of work, even when authorised to work on GCC). Maybe we could share hints on this issue -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France
regenerating reliably GCC configure files
Dear all,
I am not sure to understand what is the *reliable* way to regenerate
GCC configure files from the real (human typed) master source files
(like Makefile.in, gcc/configure.ac, Makefile.tpl, etc...)
I made some suggestions on the Wiki
http://gcc.gnu.org/wiki/AboutGCCConfiguration
Again, feel free to edit the above page (and/or incorporate parts of
it into the documentation).
And I am using (on Debian/Sid/AMD64, with additional autoconf-2.59
inside /usr/local) the following regen-basile-gcc script (explicitly
in the public domain, without warranties of any kind)
#! /bin/sh
set -x
GCCTOP=${1:-/usr/src/Lang/basile-ggcc/}
cd $GCCTOP || { echo failed to cd $GCCTOP ; exit 1 }
echo
pwd
rm -rf autom4te.cache */autom4te.cache
pwd
autogen Makefile.def
autoreconf2.13
echo
cd gcc/
pwd
autoreconf-2.59
echo done regen-basile-gcc
Actually, I have two wishes
First, to have the exact process of regenerating configure files
documented in the GCC internal documentation
Second, to have some script (perhaps in contrib/) within the source
tree which does that.
Maybe both are already there, my apologies if I didn't found them (but
I did seek them).
BTW, I cannot submit a patch for this because while it is trivial in
my view, it would exceed the 10 line limit, and my copyright
assignment is not signed yet (but it will be signed soon). Is it
permitted to submit trivial patches of a bit more than 10 lines while
the copyright assignment is pending?
With Sebastian Pop I am patching the configure machinerey to add
additional libraries usable by GCC, such as the Parma Polyhedra
Library. IF you are curious, this tentative patch (not yet working) is
available on http://starynkevitch.net/Basile/ggcc-basile.tgz and its
md5 is http://starynkevitch.net/Basile/ggcc-basile.md5 ; actually
these URL contains an automated backup of my work...
When I run my script, I'm getting
% regen-basile-gcc
+/home/basile/scripts/regen-basile-gcc:3> GCCTOP=/usr/src/Lang/basile-ggcc/
+/home/basile/scripts/regen-basile-gcc:4> cd /usr/src/Lang/basile-ggcc/
+/home/basile/scripts/regen-basile-gcc:5> pwd
/usr/src/Lang/basile-ggcc
+/home/basile/scripts/regen-basile-gcc:6> rm -rf autom4te.cache
gcc/autom4te.cache
+/home/basile/scripts/regen-basile-gcc:9> pwd
/usr/src/Lang/basile-ggcc
/home/basile/scripts/regen-basile-gcc:10: no matches found: */autom4te.cache
+/home/basile/scripts/regen-basile-gcc:12> pwd
/usr/src/Lang/basile-ggcc
+/home/basile/scripts/regen-basile-gcc:13> autogen Makefile.def
+/home/basile/scripts/regen-basile-gcc:14> autoreconf2.13
+/home/basile/scripts/regen-basile-gcc:16> echo
+/home/basile/scripts/regen-basile-gcc:17> cd gcc/
+/home/basile/scripts/regen-basile-gcc:18> pwd
/usr/src/Lang/basile-ggcc/gcc
+/home/basile/scripts/regen-basile-gcc:19> autoreconf-2.59
aclocal:configure.ac:1120: warning: macro `AM_LC_MESSAGES' not found in library
configure.ac:1120: error: possibly undefined macro: AM_LC_MESSAGES
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf-2.59: /usr/local/bin/autoconf-2.59 failed with exit status: 1
+/home/basile/scripts/regen-basile-gcc:21> echo done regen-basile-gcc
done regen-basile-gcc
I don't understand why and when do I get the warning about
AM_LC_MESSAGES
And I am getting the same error (with the same script) when running it
on a pristine gcc trunk SVN tree of svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 118865
Node Kind: directory
Schedule: normal
Last Changed Author: pbrook
Last Changed Rev: 118864
Last Changed Date: 2006-11-15 19:12:17 +0100 (Wed, 15 Nov 2006)
Could experts who are hacking the master files for configuration
please share their reconfiguration script or experience? This is
making me crazy! And if these people have write access to the GCC
trunk, I would be pleased to help them to document it, or adding such
a script... Alternatively I would be delighted if they could
contribute to the Wiki...
Regards.
NB: mail sent to both the gcc mailing list and the private globalgcc list
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: regenerating reliably GCC configure files
Le Wed, Nov 15, 2006 at 03:00:21PM -0500, David Fang écrivait/wrote:
> > I am not sure to understand what is the *reliable* way to regenerate
> > GCC configure files from the real (human typed) master source files
> > (like Makefile.in, gcc/configure.ac, Makefile.tpl, etc...)
> >
> > I made some suggestions on the Wiki
> >
> > http://gcc.gnu.org/wiki/AboutGCCConfiguration
> >
> >
> > Again, feel free to edit the above page (and/or incorporate parts of
> > it into the documentation).
>
> Hi,
>
> My initial reaction is "Why title the page \"About GCC
> Configuration\"" when the first line says it's about something else. I
> recommend a title like "... Configure auto-generation" or "...
> regeneration". You can still explain the distinction in the introduction,
> since people still often mistake the procedures.
> Some links to download the required versions of the autotools
[...]
A big thanks to David Fang for his comment. I just updated the wiki.
But I still cannot figure out how to regenerate *reliably* (and in a
reproductible way) the various configure scripts in the source tree
from the master files.
the script in http://gcc.gnu.org/ml/gcc/2006-11/msg00587.html don't
work (macro `AM_LC_MESSAGES' not found)
The steps
autogen Makefile.def
autoconf2.13
cd gcc
autoheader-2.59
autoconf-2.59
seems to work now but I remember having gotten the imfamous macro
`AM_LC_MESSAGES' not found error
what is the exact role of the autom4te.cache/ directories (I thought
that these are cache -only to speedup things- directories which are
not in the distribution and can be removed)?
Are autoreconf scripts harmful or unneeded?
How do configuration experts regenerate the configure scripts? I wish
it could be completely documented, or be a script under contrib/
By experience, sometimes autoconf-2.xx has to be run twice. When?
It seems that it is not possible to have some compiler options (like
-f* to gcc) disabled by --disable-* or --without-* flags because the
common.opt file doesn't have any "conditionals"
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: regenerating reliably GCC configure files
Le Thu, Nov 16, 2006 at 03:33:23PM -0500, David Fang écrivait/wrote:
> > > > I made some suggestions on the Wiki
> > > >
> > > > http://gcc.gnu.org/wiki/AboutGCCConfiguration
> > > >
> > > > Again, feel free to edit the above page (and/or incorporate parts of
> > > > it into the documentation).
>
> Looks like it was relocated to:
> http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
Yes, as you (David Fang) suggested. Should I add a note in the old
place AboutGCCConfiguration (I don't know if the wiki permit "symbolic
links" or "page redirection" IYSWIM)?
I have a suggestion: use the subversion property mechanism to add
metainformation about how some source files are generated by other
source files.
For example
svn ps gcc:generated-from 'Makefile.tpl Makefile.def' $GCCTOP/Makefile.in
svn ps gcc:generating-command 'autogen Makefile.tpl' $GCCTOP/Makefile.in
Does that makes sense?
Are SubVersion properties used in the GCC subversion tree? Apparently
not, except for standard Svn and Svk properties...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: build gcc with distcc
Hello
Le/On Fri, Nov 17, 2006 at 07:26:55AM +, Weidong Cui écrivait/wrote:
> I am trying to build gcc with distcc on 3 linux
> boxes. But when I build gcc with option '--enable-bootstrap',
> the 'distcc' doesn't work. So I disabled bootstrap , then 'distcc'
> worked effective.
No distcc does work, but not for the bootstrap stage (which cannot be
easily distributed). For the previous stages (like stage1) it does
work.
> My question is: how to build gcc bootstrap with distcc correctly.
> ^
I believe it is impossible in the general case. bootstrap means to
compile GCC source code with a GCC compiler just built from the same
source code. Hence, to distribute this compilation with distcc, you'll
need to send the (stage1 compiled) GCC binaries on the network, and
distcc is not able to send binary programs. (If you'll extend distcc
to send binary programs - a non trivial task -, you open a new can of
worms, and you'll need to tackle potential security issues).
So a distributed build has to also distribute files, for example by
sharing a common distributed file system. OF course details are
complex.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: build gcc with distcc
I forgot to mention IceCream http://en.opensuse.org/Icecream
which could be an alternative do distcc (that I didn't use yet).
PS On Debian, the packages are icecc [distributed compiler (client and
server)] & icecc-monitor because there the icecream package is a radio
stream download utility.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
disabling GCC flags at configure time
I am thinking of extending the *.opt machinery (ie the
gcc/opt-functions.awk gcc/optc-gen.awk gcc/opth-gen.awk files) to
offer some GCC options which can be disabled or enabled by an
appropriate configure flag.
More precisely, configure can generate HAVE_* and ENABLE_* flags
(usually in the gneerated $GCCBUILD/gcc/auto-host.h). My intent is to
hack so that the code corresponding to some flags (eg those marked
with CppCondition(HAVE_FOO) in common.opt) is conditionally generated
with #if defined(HAVE_FOO) && HAVE_FOO!=0 in files
$GCCBUILD/gcc/options.c and $GCCBUILD/gcc/options.h
A typical use could be to provide more expansive optimisations or
analysis. These could be enabled at configure time with
$GCCTOP/configure --enable-foo and then a -fanalys-foo flag is
possible in GCC. Otherwise (if configure got --disable-foo) such a
flag has no sense.
Any comments?
BTW, my copyright assignment (to FSF) has been signed by my
organisation (CEA-LIST where I am employed) and is currently either
flying (by Chronopost express) above the atlantic, or pehaps soon
arrived in Boston at FSF (but since it is Thankgiving I could expect
some delay). Hence, I believe I can now legally submit patches which
exceed 10 lines.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: disabling GCC flags at configure time
Hello All
In a previous message I (Basile S.) wrote on Fri, Nov 24, 2006 at
08:54:31PM
>
> I am thinking of extending the *.opt machinery (ie the
> gcc/opt-functions.awk gcc/optc-gen.awk gcc/opth-gen.awk files) to
> offer some GCC options which can be disabled or enabled by an
> appropriate configure flag.
>
> More precisely, configure can generate HAVE_* and ENABLE_* flags
> (usually in the gneerated $GCCBUILD/gcc/auto-host.h). My intent is to
> hack so that the code corresponding to some flags (eg those marked
> with CppCondition(HAVE_FOO) in common.opt) is conditionally generated
> with #if defined(HAVE_FOO) && HAVE_FOO!=0 in files
> $GCCBUILD/gcc/options.c and $GCCBUILD/gcc/options.h
I am a bit ashamed to not have re-read the documentation. Perhaps the
Condition() option syntax might be perhaps used. From
$GCCTOP/gcc/doc/options.texi (file rev119164 from trunk)
@item Condition(@var{cond})
The option should only be accepted if preprocessor condition
@var{cond} is true. Note that any C declarations associated with the
option will be present even if @var{cond} is false; @var{cond} simply
controls whether the option is accepted and whether it is printed in
the @option{--help} output.
However, I grepped the source and did not found any use of this in any
gcc/*.opt file. Does anyone have an idea why this Condition is still
there?
And my initial proposal (which I called CppCondition) is slightly
different (and more general, perhaps safer) If the preprocessor
condition is false, the C variable for the flag should be not even
generated. (hence any reference to it will fail at Gcc build time).
Comments please?
Happy Thanksgiving to north americans, and regards to everyone.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
what about a compiler probe?
Dear All,
I am considering implementing the following feature into GCC using the
patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html : a
compiler probe which permits to probe the run of a compilation,
e.g. by displaying in emacs or a graphical GTK application the current
pass, Gimple representations, etc... which effectivly probes inside
the compiler; this could be useful for long-lasting compilations (in
particular those considered in the globalGCC project
http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html which will probably
"compile" tens time slower than current gcc) of more than several
minutes, or for GCC hackers which want to debug or understand its
internal by experimenting it. For example, it could be useful to know
the currently compiled function, or the current Gimple trees for it,
etc... In general do you feel that such a feature could be useful? (it
somehow generalize Sebastian Pop's gcc/tree-browser.c)
I propose a --enable-compiler-probe flag to configure which by default
is disabled. When GCC is configured with --enable-compiler-probe
(which is only possible on some Posix or Unix hosts like linux & BSD &
Solaris), the resulting compiler
accepts a -fcompiler-probe flag; in the usual case where this flag
is not passed, the compiler does not behave differently than usual,
except probably a minor performance hit (which won't happen when
configured with --disable-compiler-probe).
when given the -fcompiler-probe flag, it should get an a string
option with it. If this string is a (Unix) file path it indicate a
Unix socket or FIFO; if it starts with a vertical pipe bar | it
starts the command and communicate with it thru pipes. Typically the
command is some client application (either a GTK graphical
interface, or an Emacs, or perhaps a FastCGI) which communicates
with GCC thru a textual protocol to be defined and documented.
The textual protcol should permit to examine, but not change, the
compilation state. For a lenghtly static analysis, it could be used to
show the properties the compiler currently know about a given
(compiled) source point.
Since I don't want to add multi-threading into GCC, my plan is to
implement this (only on Linux & BSD hosts!) by using old asynchronous
I/O, ie the F_SETOWN fcntl, the select system call, so that when some
input arrives on the channel, some routine might parse the input and
respond accordingly. The dirty trick is to have some volatile
sig_atomic_t varible which is set (by a SIGPOLL handler) and routinely
checked
/* set by SIGPOLL on input */
extern volatile sig_atomic_t comprob_interrupted;
The difficult part is to implement the probing routine
void comprob_compiler_probing(const char*file, int line);
I assume that the probed state is in some global GCC
variables. Otherwise, we need more arguments to pass them.
Then at appropriate places within the compiler the following macro is
called
#define comprob_maybe_probe() do{if (comprob_interrupted) \
comprob_compiler_probing(__FILE__,__LINE__): } while(0)
And then we could add many calls to the above macros. This is not
pretty, but in my experience on other software works quite well. and
is not that much intrusive (except in the source by addition of many
occurrences to this macrfo, and which executing by testing quite often
a volatile variable).
Feel free to tell me that it is a crazy idea. But remember that the
context is long-lasting compilations.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: what about a compiler probe?
Le Mon, Nov 27, 2006 at 11:54:20AM +1100, Ben Elliston écrivait/wrote:
> > I am considering implementing the following feature into GCC using
> > the patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html
> > : a compiler probe which permits to probe the run of a compilation,
> > e.g. by displaying in emacs or a graphical GTK application the
> > current pass, Gimple representations, etc..
>
> What you're describing sounds a bit like the VISTA interactive
> compilation environment which allows users to dynamically adjust the
> optimisation regime of individual functions and examine the effect:
>
> http://citeseer.ist.psu.edu/433065.html
A big thanks for your reference.; I am glancing at it.
But my idea, within the GlobalGCC project
http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html (where we expect analysis to
last dozens of minutes of compilation time on a whole program) was not to
drive interactively the compilation (or the analysis), but only to show
interactively the results of static analysis (and also, using the same
machinery, of already existing transformations) and more genera lly some
current state of the (long lasting) compilation.
static analysis produce a large amount of data which could be useful to
users. Nearly all the static analysers I know about have some user
interface; usually by being able to show to the user the information
computed for a given control point (or source location) See in particular
http://www.di.ens.fr/~goubault/papers/icse01.ps.gz
I see two alternatives:
either plug a "compiler probe" like the one I suggested initially.
alternatively, dump some of the intermediate results on the disk and have a
utility to display it offline.
(BTW, I could postopone the decision later)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
why gengtype not a filter for GTY?
Dear All (and especially those implied in the GCC internal garbage
collector).
I read (and contributed a bit to) http://gcc.gnu.org/wiki/Memory_management
and also read http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html
However, there is still a question which puzzles me a lot? Why gengtype is
not a sort of filter or generator (like yacc is) taking a (list of) files on
input and producing a file on output?
More precisely, why gengtype does not take the name of files to be parsed
for GTY(()) thru its program argument (ie argc,argv of its main - they are
explicitly marked as unused in $GCCTOP/gcc/gengtype.c)
I would believe it should make things simpler (in a lot of places) but I
cannot understand why it is not so? Why are the set of files to be parsed
for GTY()) so hard-coded in gengtype?
BTW, it is strange that gengtype* files do not mention any author or
contributor (with an email to contact them)?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
CEA (France) has signed assignment of copyright to FSF on GCC
Dear All,
Sorry to disturb uninterested people with following information
For information (and for future reference) my employing organisation CEA
http://www.cea.fr/ "Commissariat a l'Energie Atomique, a French state-owned
research entity with a scientific, technical, and industrial activity duly
organized under the laws of France, ", has signed an assignment of
copyright in the GNU Compiler Collection
The copyright assignment (signed on november 20th 2006 by R.Cammoun,
Director of CEA-LIST) has reference RT306238 ; in my understanding (but I am
not a lawyer) it could be applicable to any of the 14,910 employees of CEA
who is or will submitting patches to GCC.
I apologize for sending this here, but I thought that it could be the place
to tell this, and it could interest (now or in the future) some distant CEA
collegues (CEA is big enough for that) that I do not know and cannot reach
otherwise.
BTW, I am surprised that it is not easy to know which organizations exactly
has signed such legal papers. It could happen (in big organizations) that
such an assignment has been signed, and a putative minor contributor to GCC
does not know about it yet.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Announce: MPFR 2.2.1 is released
Le Tue, Dec 05, 2006 at 07:12:08AM -0500, Diego Novillo écrivait/wrote:
> Kaveh R. GHAZI wrote on 12/04/06 21:32:
> >That idea got nixed, but I think it's time to revisit it. Paolo has
> >worked out the kinks in the configury and we should apply his patch and
> >import the gmp/mpfr sources, IMHO.
> Yes, I vote to include gmp/mpfr in the tree. If gmp/mpfr is still a
> fluid target, we could add svn glue code to avoid commits to the
> sub-tree and rely exclusively on wholesale import.
I'm not sure to follow Diego and I am a bit concerned about other
potential external libraries. Suppose for example that some GCC code
uses an external library like the Parma Polyedral Library
http://www.cs.unipr.it/ppl/ (which is very useful for sophisticated
static analysis) or the Libtool Dynamic Loader, which might be useful
also, for example if the compiler needs to generate some specialized
(w.r.t. to the compiled source code) code. Maybe my position is
unusual, but I believe that more and more external libraries or
softwares will become required or useful to GCC.
More generally, I believe that some kind of compilations (ie some
specialized passes or frontends ...) would more and more need external
libraries. And I do not understand the need to incorporate the source
code of these libraries into GCC Subversion tree. This argument
already stands for Binutils or bison and could even stand for Boehm's
GC or perhaps SubVersion or bash or GNU make
I really tend to believe that the configure machinery should permit
external libraries (and I welcome the --with-gmp-lib &
--with-gmp-include configure flags) and check for required versions,
but I have trouble to understand why should these libraries be
included into GCC (source tree, as managed by SubVersion in the
trunk).
So my current opinion is still that the GMP & MPFR source should stay
away of GCC (but that the configure script should check for their
installed versions). The only case where this could be invalid is when
GCC would requires a slightly patched GMP or MPFR (ie if the upstrream
authors of these GMP/MPFR/.. libraries refused to incorporate some
required patch). This in practice would mean a fork of these external
libraries, which we should try to avoid.
As a sidenote, I would believe that most GCC users (not contributors!)
do not compile the GCC source code, but usually use the compiler that
some (e.g.) Linux distribution (or other build) offers them. Then the
effort cost for building GCC is on the distributions maintainers, not
on GCC users.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
destruction of GTY() data
Hello
I am not sure to understand what if_marked or deletable means in GTY context
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
http://gcc.gnu.org/wiki/Memory_management
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (this should indeed be
possible, since GGC is a mark& sweep garbage collector, which delet
individually each dead data).
More precisely, I want to ha a GTY data which contains either an MPFR
http://www.mpfr.org/ data, or a PPL (Parma Polyhedra
Libraryhttp://www.cs.unipr.it/ppl/ ) data. Hence the underlying MPFR
(or PPL) destruction routine (like mpfr_clear or
ppl_delete_Coefficient) should be called.
How can I achieve this?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: destruction of GTY() data
them to be uncommon, and rather small (since
the bulk of their content is elsewhere).
Note (*) I don't know yet where their mark should be
In ggc-page.c I think of coding the following:
Keep all destroyable objects in a separate bag of pages and handle
their allocation appropriately there.
In ggc_collect before the call topoison_pages add a call which
calls the destructor of every unmarked destroyable object.
etc...
In ggc-zone.c I think of coding the following
manage a special alloc_zone destroy_zone for destroyable objects
and have a struct destr_page_entry
hack sweep_page to handle these destr_page_entry etc...
I don't have all the details right now, but I am asking for your
comments. I do depend that current GC implementations are mark & sweep
variety (but Boehm's GC can be used with similar destructors).
I believe that:
1. adding some support for destroyable objects is not only of
interest to me, but to others (eg those wanting to add arbitrary
precision constants in garbage collected trees).
2. given that destroyable objects are rare (w.r.t. others)
performance should not suffer much
3. the commodity of such destroyable objects could be useful in the
future
4. for the future, having every dynamically allocated object
containing a common descriptive pointer or prefix (like in the Glib
of GTK, or the vtable in C++, or implementation of values in Ocaml)
would permit more freedom in various GC implementations, and in
addition is valuable for debugging and others.
(IMHO the tuple effort is going towards this, but I am not
sure if it defines a principle that every GCC data should start
with a common prefix; in object oriented parlance, I would prefer a
single tree of inheritence, not a forest of independent
hierarchies).
The last point 4 is not needed to me now, but it could help, and I see
a lot of other reasons why it could be useful. (e.g. debugging,
dumping, ...)
So please be kind to comment. Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: destruction of GTY() data
Le Sat, Dec 09, 2006 at 12:08:09AM +0100, basile écrivait/wrote:
> On Tue, Dec 05, 2006 at 09:06:13PM +0100, I (Basile) wrote in
> http://gcc.gnu.org/ml/gcc/2006-12/msg00158.html
>
> >
> > I want to have a GTY() garbage collected structure such that, when it
> > is destroyed, some specific routine is called (this should indeed be
> > possible, since GGC is a mark& sweep garbage collector, which delete
> > individually each dead data).
I forgot to mention that what I am taling about can be viewed as some
restricted form of finalized objects (with the important caveat that I
don't tackle the difficult issue of what happens when the finalizer
change the graph of memory references to GGC objects. I disallow
this).
>
> Zack Weinberg wrote in http://gcc.gnu.org/ml/gcc/2006-12/msg00159.html
>
> > On the other hand, I sympathize with your goal; I've been idly
> > thinking a little myself about the sensibility of using MPFR
> > throughout, instead of our bespoke REAL_VALUE_TYPE thing. [I don't
> > know if this is actually a good idea yet.]
I don't understand very well this REAL_VALUE_TYPE thing. Could you
ellaborate, please? I did have a glance into gcc/real.h
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: destruction of GTY() data
Le Fri, Dec 08, 2006 at 07:09:23PM -0500, Daniel Berlin écrivait/wrote:
>
> Uh, well, you see, there are points in between these two extremes.
> Most commercial compilers are not garbage collected, they rely on
> allocation pools (ie multiple heap) to get sane performance and
> lifetime management.
I know about some compilers or static analyzers coded in SML, Ocaml,
Java which are commercially sold (or open source, and used in
commercial products). At some point in the past, the PolySpace
analysers http://www.polyspace.com/ which are quite expensive, where
rumored to be coded in SML. And ASTREE
http://www.di.ens.fr/~cousot/projets/ASTREE/ is coded in Ocaml. But
reliable information about the internals of these tools are hard to
get. I did work on some proprietary static analyser prototype, and we
needed to add a garbage collector inside it. For the algorithms
considered, coding without any automatic memory managment would be a
nightmare, and I won't even dare trying.
I'm working within (and I am paid by) the GlobalGCC project
http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html which aims at adding
global static analyis which is expected to be very expensive (probably
compilation times ten or more times slower).
> You see, we currently waste a lot of memory to avoid the fact that our
> GC is very slow.
> We still take it on the chin when it comes to locality. Previous
> things such as moving basic blocks from alloc_pools (which are
> contiguous) to gc'd space cost us 2-3% compilation time alone, because
> of how bad our GC places objects.
Even 25% of current GCC compilation time is a noise level to me. If I
achieve 1000% of current GCC -O3 compilation time, I will be very
proud of me. So I really do not care about 3%, and I thought that my
proposal won't cost a lot if it is not used (because if they are no
finalized object, GCC won't run much slower...).
>
> This just isn't that big a problem. If you want to associate these
> things with trees, put them in annotations, mark them GTY ((skip)) and
> explicitly manage their lifetime. It is highly unlikely that they are
> going to live for some indeterminate amount of time.
So basically you are suggesting me to add some kind of specific
garbage collection machinery within my pass. Could be ok, but painful.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: destruction of GTY() data
O, Sat, Dec 09, 2006 at 11:03:21AM -0500, Daniel Berlin écrivait/wrote: > On 12/9/06, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > >Le Fri, Dec 08, 2006 at 07:09:23PM -0500, Daniel Berlin écrivait/wrote: > > > >> You see, we currently waste a lot of memory to avoid the fact that our > >> GC is very slow. > >> We still take it on the chin when it comes to locality. Previous > >> things such as moving basic blocks from alloc_pools (which are > >> contiguous) to gc'd space cost us 2-3% compilation time alone, because > >> of how bad our GC places objects. > > I wrote the paragraph below, but it was poorly phrased and I apologize for having mis-expressed my thoughts. > >Even 25% of current GCC compilation time is a noise level to me. If I > >achieve 1000% of current GCC -O3 compilation time, I will be very > >proud of me. So I really do not care about 3%, and I thought that my > >proposal won't cost a lot if it is not used (because if they are no > >finalized object, GCC won't run much slower...). The 3%, 25% or 1000% figures (only a guess) above are only for global static analysis passes. They are not for the usual GCC passes used by everyone with -O2 (or even -O3). I should have emphasized that I do not care in 3% for the overall cost of future expensive static analysis passes (which the project GlobalGCC is about), not for the usual performance of the compiler (for which like every one I care about). Of course 3% is meaningful in the usual compiler run (typically -O2) and I am careful to avoid spoiling it. Sorry for having phrased my sentence wrongly.; I repeat myself, the huge overhead I am considering is only for expensive static analysis passes which are usually disabled. Hence I am discussing here some ideas to avoid spoiling the compiler, while still bringing *usually disabled* features which could be useful to global static analysis and perhaps also to other (expensive) passes of GCC. I do care a lot about not increasing compile time when these expensive passes are disabled. My expertise is more about static analysis to produce human readable warnings, much like commercial tools like PolySpace offer. This means analysing small to medium sized programs (typically less than a few hundred thousand lines of source code) whose source is fully available. And my contractual obligations inside GlobalGCC (w.r.t those funding my work) is mostly to deliver some global static analysis passes. > > > >> > That's great. If you want to make a compiler useless to almost > everyone, go for it. Do it on a branch, go wild. I'm sure there are > 6 or 7 people in the world who will use it because it matters to them > that much. First, the GlobalGCC project is about adding global static analysis which of course can and should be usually disabled. So of course I am careful to not spoil the trunk. All the equivalent static analysis tools I know about do run much slower than a compiler, and this is expected and normal by their users. And they are people who still are interested and buying them. So there is a niche market for such a project (otherwise it won't have been funded). For example Airbus (which is inside the GlobalGCC consortium) routinely use static analysis tools for analysis of industrial strength critical code (flying in A330, A350, A380). Also Mandriva is inside the consortium because they wanted a tool which helps them to port all the software in the Mandriva linux distributions to 64 bits hosts (currently this task costs them dozen of man years). Other industrials in the consortium and outside also care about static analysis (but I am not speaking for any of them). The end-result of GlobalGCC should be something like a set of additional passes, which can be disabled both at configuration time and at GCC compile time and which are usually disabled, unless a -fdo-globalgcc-analysis [or call it what you like] is explicitly given to the resulting GCC (which has been configured at build time with something like -enable-globalgcc-analysis). Do you agree a priori that providing a set of passes which are usually disabled should not significantly impact the daily performance of GCC? When the user requests them (thru -fdo-globalgcc-analysis or whatever other flag) and when the GCC has been configured at build time to provide them, additional global static analysis occurs. Otherwise, they are not called at all. Again, a gate in a struct tree_opt_pass which starts with if (!flag_globalgcc_analysis) return 0; should not cost much (much less than 1% or even 0.1% hopefully), in the usual event where flag_globalgcc_analysis is always cleared. When requested, it is expected that we will provide whole program static analysis. This means that we somehow need the -fwhole-program -combine flags to GCC. By the way, this current op
configuration options policy (at toplevel or only inside gcc/)?
Hello,
Most options of GCC (like --enable-werror --with-gmp ...) are configure-able
at its toplevel source directory while others ( --enable-mapped-location
) are configure-able with the configure script inside its gcc/ source
subdirectory
Of course, some options are for the whole toplevel.
When adding a new option, should I always add it at the toplevel or not?
Some options (like --enable-mapped-location or --with-gc=zone) seems to be
only usable with the gcc/configure script which seems usually to be run by
the build procedure (ie by the make at build).
Actually, I don't fully understand what might go inside the toplevel. I
believed that once perhaps even gdb or binutils could go there but I might
be wrong...
In other words, should I make all my configurable flag visible by the
toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not?
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: configuration options policy (at toplevel or only inside gcc/)?
Le Thu, Dec 14, 2006 at 08:56:27AM -0500, Daniel Jacobowitz écrivait/wrote:
Thanks to Daniel for his reply!
> On Thu, Dec 14, 2006 at 10:19:12AM +0100, Basile STARYNKEVITCH wrote:
> > In other words, should I make all my configurable flag visible by the
> > toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not?
> No, you shouldn't. Only add them to subdirs that need them.
This makes life much simpler to me, but then I do not understand how end-
users compiling GCC are expected to configure it. Does this mean that the
instructions on http://gcc.gnu.org/install/configure.html are no more valid
for that case?
What should be the user installation & configuration procedure replacing the
# from http://gcc.gnu.org/install/configure.html
mkdir objdir
cd objdir
srcdir/configure [options] [target]
in that case?
Should it become
mkdir objdir
cd objdir
srcdir/configure [options-to-toplevel] [target]
cd ../objdir/gcc # or simply gcc, but in the build tree
srcdir/gcc/configure [options-to-gcc] [target]
At last I do not understand why the MPFR & GMP stuff which has been
discussed a lot is not already under the above scheme? Why is it cheched at
toplevel and not only in gcc/ ? AFAIK the #include appears only in
gcc/real.h
BTW, I am working on add stuff (heavy global static analysis) which
should be disablable at configure time and at runtime, and uses several
third parties (GPL or LGPL) libraries
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: configuration options policy (at toplevel or only inside gcc/)?
Le Thu, Dec 14, 2006 at 07:29:19AM -0800, Ian Lance Taylor écrivait/wrote:
> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>
> > This makes life much simpler to me, but then I do not understand how end-
> > users compiling GCC are expected to configure it. Does this mean that the
> > instructions on http://gcc.gnu.org/install/configure.html are no more valid
> > for that case?
>
> Note that configure options beginning with --with and --enable are
> passed from the top level configure script to the subdirectory
> configure scripts. So the user just uses all the options at the top
> level, and the subdirectories will see them.
I did notice this, but it seems to me (maybe I am wrong) that there is
no generic machinery which passes the --with & --enable of the
top-level configure to the configure in gcc subdirectory. There is
some code in Makefile.tpl for this, but each such option has to be
explicitly & individually processed.
In other words for adding new configure options to gcc/ subdirectory,
we have to hack the gcc/configure.ac file, the toplevel configure.in
and the toplevel Makefile.tpl and this should be done for every
user-visible options. Otherwise, it is an option which is not visible
to the user. If I hack only gcc/configure.ac, I am adding an option
which the user do not see. Is this correct?
> I agree that new options should only be added at the appropriate
> level, but there is one disadvantage: top level configure --help will
> not display them. But then configure --help is kind of useless anyhow
> since it has so much boilerplate, so this is not a significant
> problem.
Still, what is the build procedure then? Do we expect users to type
two configure commands?
>
> > At last I do not understand why the MPFR & GMP stuff which has been
> > discussed a lot is not already under the above scheme? Why is it cheched at
> > toplevel and not only in gcc/ ? AFAIK the #include appears only in
> > gcc/real.h
>
> It's at the top level because the original implementation envisioned
> support for putting MPFR and GMP in the tree, alongside of the
> directories gcc, libcpp, etc. That may still happen.
Thanks for the explanation. But I thought it has been firmly decided
to keep GMP & MPFR outside!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: configuration options policy (at toplevel or only inside gcc/)?
On Thu, Dec 14, 2006 at 06:32:41PM +0100, Ralf Wildenhues wrote:
>
> You may find this discussion currently on the Autoconf list helpful:
> http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/8755
Thanks to all (Daniel Jacobowitz, Ian Lance Taylor, Paolo Bonzini,
Ralf Wildenhues).
I partly updated the Wiki. It is sad that nobody corrected the page
http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
(I hope I corrected some stuff there, and I wrote most of it).
I really think that such information should go into GCC internal
documentation, where I was not able to find it out. Do you believe
that some of the descriptions in this thread and in the Wiki page just
cited should go into the documentation? Is the documentation expected
to help new GCC contributors, or is it only for users? In particular,
IMHO the commands to re-generate the configure scripts should be
documented if the documentation also targets potential GCC
contributors.
I could write (by copying phrases from the wiki page) a few sentences
into the documentation (gcc/doc/sourcebuild.texi)? Is it worthwhile;
in other words for whom is this documentation written: for users of
GCC (including the few people compiling GCC to use it) or for
potential contributors (GCC hackers)?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
getting source locations ....
Hello All,
I am interested in getting the source location (at least the start
source file, linenumber, and possibly column number and end source
file, linenumber, ...) of
a GIMPLE/SSA tree (I want the corresponding source location, I very
much realize that the source location might not exist)
a basic block
a cgraph node
So far, for the GIMPLE/SSA tree, I'm doing something like
/***
* return true if a (GIMPLE/SSA) tree TR has a position
* and in that case fill the PFILENAME and PLINENO
***/
bool comprobe_get_position(tree tr, char**pfilename, int* plineno)
{
if (EXPR_P (tr))
{
const char **pfile = expr_filename (tr);
if (pfile)
{
*pfilename = *pfile;
*plineno = EXPR_LINENO (tr);
return;
}
}
else if (GIMPLE_STMT_P (tr))
{
const char **pfile = expr_filename (tr);
if (pfile)
{
*pffilename = *pfile;
*plineno = EXPR_LINENO (tr);
}
}
else if (GIMPLE_TUPLE_P (tr) && GIMPLE_TUPLE_HAS_LOCUS_P (tr))
{
#warning dont know how to get location of a tuple
gcc_unreachable ();
}
if (TREE_CODE (tr) == STATEMENT_LIST)
{
tree_stmt_iterator iter;
tree tr_stmt;
for (iter = tsi_start (tr_body); !tsi_end_p (iter);
tsi_next (&iter))
{
tr_stmt = tsi_stmt (iter);
if (comprobe_get_position(tr_stmt, pfilename, plineno))
return TRUE;
}
}
return FALSE;
}
For a basic block, I don't know how to handle it
for a cgraph (cgr), since I'm interested in getting the location of the body of
functions, I would do something like
tree tr_body = DECL_SAVED_TREE(cgr->decl);
return comprobe_get_position(trbody, pfilename, plineno)
I welcome any comments or advices Notice that I don't know how to
get location of tuple trees.
I do know that this position information is not always available, but
I also know that the debugging information which is output with the -g
option is usually quite smart on this, so the information is somehow
"usually" available.
(I'm working on the compiler probe idea, and on static analysis, so I
am interested in being able to show various infered properties about
gimple trees, and later to produce possible warnings about them).
I wish a very happy New Year 2007 to evryone!
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: identifing free() in tree-ssa
On Tue, Jan 02, 2007 at 02:30:45PM -0700, Roger Sayle wrote:
>
> I think recognizing "free" as a built-in (without an intrinsic) is the
> correct way to go. In theory, all of the functions listed in
> cp/cfns.gperf should be defined via builtins.def, but unfortunately
> the compile-time (and memory) overhead of constructing a large number of
> builtins at run-time is already noticeable. Hence, we only define
> those that are most useful [even though I'd like to optimize away calls
> to qsort where n is a compile-time constant zero or one! :-)]
>
> If anyone has any ideas on how best these builtins can be constructed
> statically and/or lazily, conveniently for those front-ends that can
> benefit from them, I'd be very interested in suggestions.
Maybe, instead of using built-ins, we could extend the __attribute__
facility for functions (and expect the libc developers to progressively use
them). Eg
void free(void*) __attribute((pointer_invalid(1)));
would mean that argument #1 of function free is pointer which is invalidated
by the function. Or maybe a pragma for that
Of course, the challenge is then how to have lots of attributes, and not
slow down the compiler... I don't know yet if adding hundreds on definitions
inside gcc/builtin-attrs.def would slow down the compiler.
IMHO, adding new attributes would permit future library developers to
annotate their header files appropriately. This would be more powerful than
understanding only a given standard symbol like free. Of course, the cost of
attributes is that to use them effectively we depend upon library developers
using them actually in their headers.
Happy new year 2007 to everyone.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
mixing VEC-tors of string & GTY?
Hello All,
I cannot figure out how to have a vector of strings in a GTY-ed file
As a simple example, if I add (inside trunk rev.101317) at the end of
gcc/stringpool.c just before the last #include "gt-stringpool.h"
typedef char* basilestring_t;
DEF_VEC_P (basilestring_t);
DEF_VEC_ALLOC_P (basilestring_t,heap);
static VEC(basilestring_t,heap) *basilestring_vector;
Then I gen a gengtype error:
make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
build/gengtype
/usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type
`basilestring_t'
Notice that:
I do not add any additional occurrence of GTY in a already GTY-ed file.
my added code is quite similar to the following code from gcc/genextract.c
(which is not gengtype-d)
typedef char *locstr;
/*later*/
DEF_VEC_P(locstr);
DEF_VEC_ALLOC_P(locstr,heap);
Any clues?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: mixing VEC-tors of string & GTY?
Le Thu, Jan 04, 2007 at 05:30:37AM -0500, Andrew Pinski écrivait/wrote:
> >
> >
> > Hello All,
> >
> > I cannot figure out how to have a vector of strings in a GTY-ed file
> >
> > As a simple example, if I add (inside trunk rev.101317) at the end of
> > gcc/stringpool.c just before the last #include "gt-stringpool.h"
> >
> > typedef char* basilestring_t;
> > DEF_VEC_P (basilestring_t);
> > DEF_VEC_ALLOC_P (basilestring_t,heap);
> > static VEC(basilestring_t,heap) *basilestring_vector;
> >
> > Then I gen a gengtype error:
> > make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> > build/gengtype
> > /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type
> > `basilestring_t'
> >
> > Notice that:
> >
> > I do not add any additional occurrence of GTY in a already GTY-ed file.
> >
> > my added code is quite similar to the following code from gcc/genextract.c
> > (which is not gengtype-d)
> >
> > typedef char *locstr;
> > /*later*/
> > DEF_VEC_P(locstr);
> > DEF_VEC_ALLOC_P(locstr,heap);
> >
> > Any clues?
> >
> > Regards
> > --
> > Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> > email: basilestarynkevitchnet mobile: +33 6 8501 2359
> > 8, rue de la Fa?encerie, 92340 Bourg La Reine, France
> > *** opinions {are only mines, sont seulement les miennes} ***
> >
>
>
Andraw Pinksi probably hit the send key too early.
This thread is probably related
http://gcc.gnu.org/ml/gcc/2003-03/msg01258.html
but I cannot figure out any solution without patching gengtype, should I
consider
a patch like http://gcc.gnu.org/ml/gcc/2003-03/msg01265.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: mixing VEC-tors of string & GTY?
Le Thu, Jan 04, 2007 at 05:39:23AM -0500, Andrew Pinski écrivait/wrote:
> First sorry about the first email.
> > As a simple example, if I add (inside trunk rev.101317) at the end of
> > gcc/stringpool.c just before the last #include "gt-stringpool.h"
> >
> > typedef char* basilestring_t;
> > DEF_VEC_P (basilestring_t);
> > DEF_VEC_ALLOC_P (basilestring_t,heap);
> > static VEC(basilestring_t,heap) *basilestring_vector;
> >
> > Then I gen a gengtype error:
> > make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> > build/gengtype
> > /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type
> > `basilestring_t'
[...]
> Yes fix gengtype to ignore non heap gc cases.
I just submitted the patch
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00222.html which add a
magic comment parsing to have gengtype ignore stuff
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
variable-sized array fields in structure?
Hello all,
It is common to have structures which end with an "undefined"
variable-length array like
struct foo_st {
struct bar_st* someptr;
int len;
struct biz_st *tab[] /* actual size is len */;
};
I'm sorry to be unable to get the exact wording of this construct,
which I am sure is in some recent (C99? maybe) standard, unfortunately
I don't have these standards at hand.
There is even a length attribute in GTY to help support this
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
I believe the correct idiom in GCC source is to put an explicit
dimension to 1 (probably because 0 would make some old compilers
unhappy), ie to code instead
struct foo_st {
struct bar_st* someptr;
int len;
struct biz_st *tab[1] /* 1 is dummy, actual size is len */;
};
Unfortunately, when debugging (or taking sizeof), this makes a little
difference.
My small suggestion would be
1. To explicitly document that such undefined variable-sized array
fields should be declared of dimension VARYING_SIZE (or some other
word), i.e. to code
struct foo_st {
struct bar_st* someptr;
int len;
struct biz_st *tab[VARYING_SIZE] /* actual size is len */;
};
2. To have a definition of VARYING_SIZE is some of our header files
(config.h, or system.h or others) which is 1 for old compilers and
empty for new ones (including gcc itself), maybe
#if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L)
#define VARYING_SIZE 1
#else
#define VARYING_SIZE /*empty*/
#endif
Is there some point that I forgot? Probably yes, since my suggestion
is quite obvious but not yet in GCC?
Thanks for reading.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: variable-sized array fields in structure?
I just wrote in my previous message
http://gcc.gnu.org/ml/gcc/2007-01/msg00958.html []
> 2. To have a definition of VARYING_SIZE is some of our header files
> (config.h, or system.h or others) which is 1 for old compilers and
> empty for new ones (including gcc itself), maybe
>
> #if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L)
> #define VARYING_SIZE 1
> #else
> #define VARYING_SIZE /*empty*/
> #endif
I made a mistake above, I meant the symetrical
#if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L)
#define VARYING_SIZE /*empty*/
#else
#define VARYING_SIZE 1
#endif
Sorry for the mistake.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Failure to build libjava on 512MB machine
Le Wed, Jan 31, 2007 at 09:45:04AM +, Andrew Haley écrivait/wrote:
>
> I'd want a bit more information. There's no reason that a 512M box
> couldn't cope with a 550M process. Sure, it'll be slow, but it should
> still work, and this is an extreme case. If there is to be a maximum
> process size during building, we need to make a sane decision about
> what that size should be.
I personnaly am not very favorable to such a limitation (of the maxium
process size during building), because I would suppose that taking such a
decision is a slow process. In the event most people want have such a
limitation explicitly defined I hope it would ber at least some moving
limit, like "the average RAM of most PCs sold last year" and not "512Mb"
(since I am afraid such a limit would stay carved in stone for a long while,
and that a formal agreement on it would take one year to be reached).
After all, I believe that most people who actually compile GCC have a quite
fast & big machine (which I leave purposely undefined here). As an extreme
example, I won't compile GCC on a PDA!
I also acknowledge that I am living in the "first world" and that some
developers have probably much slower machines than I do. But I think that I
don't have the fastest/biggest machine (among developers') neither...
In addition, this 550Mb process size seems to occur only for some languages
(Java probably) of GCC, not all of them.
I am afraid that the GCC community would one day decide something like "no
patch is accepted if the bootstrap procedure of the patched compiler takes
more than X minutes and Y megabytes on reference platform Z" with suitable
(small) values for X and Y and Z. I hope this won't happen.
Maybe we just could put in the documentation -for information only- the
typical time, disk space & memory usage of a typical bootstrap (on a
"typicazl" but specified system), just as a hint to future developers. I
believe that disk usage is already there (but didn't find it quickly).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
trunk rev121458 dont bootstrap
Hello
(I don't know if the good mailing list for this is gcc@ or gcc-patches@)
Apparently trunk rev 121458 don't bootstrap on linux debian sid amd64 ie
x86_64-unknown-linux-gnu
I'm getting
make[4]: Leaving directory
`/usr/src/Lang/gcc-trunk/_BootObj2/x86_64-unknown-linux-gnu/libgcc'
/usr/src/Lang/gcc-trunk/_BootObj2/./gcc/xgcc
-B/usr/src/Lang/gcc-trunk/_BootObj2/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2
-O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../.././gcc -I/usr/src/Lang/gcc-trunk/libgcc
-I/usr/src/Lang/gcc-trunk/libgcc/. -I/usr/src/Lang/gcc-trunk/libgcc/../gcc
-I/usr/src/Lang/gcc-trunk/libgcc/../include
-I/usr/src/Lang/gcc-trunk/libgcc/../libdecnumber -I../../libdecnumber -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c: In function '__multi3':
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
configured with
/usr/src/Lang/gcc-trunk/configure --enable-maintainer-mode
--enable-languages=c
Does that seems familiar to anyone?
Regards!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
(OffTopic) trouble registering on www.gccsummit.org
Hello All,
Sorry for this off-topic message, but I have some troubles registering on
https://www.gccsummit.org/2007/login.php and my email to
[EMAIL PROTECTED] bounced.
My own email is [EMAIL PROTECTED]
Does anyone know who should I contact about the gccsummit.org web site or
registration system?
Regards, and apologies for this slightly off topic message! I hope someone
in charge of the gccsummit.org site would read it.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Pre Compiled Headers
Hello
On Mon, 12 Feb 2007 19:46:35 -0800 Mike Stump wrote
> The mental model you should use for PCH is this, when processing a header,
> the compiler does a complete memory walk and dumps it to a file. Upon
> `reading' the pch file, it mmaps all that memory back in, throwing out all
> previously allocated memory, and continues just after the #include.
A big thanks for the explanation, which is something I partly guessed, but
which leaves me in a deep trouble :-)
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
It seems to me that some such GTY-ed global data might explicily want not to
be reloaded, or maybe want to be always cleeared at each pch reload.
However, I am not sure there is any GTY tag for this.
I also don't understand at which point of the compilation is the PCH dumped.
For example, do PCH file contain Gimple-SSA trees (I would guess yes) or
only Generic trees?
Maybe such precious knowledge about GTY & PCH should go into the
documentation or the wiki? I did't found much information on this in
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html
A big thanks to all for the information. Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
minimal version of bison for Gcc?
Hello,
It seems according to http://gcc.gnu.org/install/prerequisites.html that the
minimal version of bison required in GCC (for those hacking the few .y
files) is 1.28 (released in july 1999).
Is there a reason why a 2.x version of bison would not be acceptable? FWIW,
I am not considering using bison in a frontend, but just to parse some kind
of "scripts" or internal data inside a (usually unused) static analysis
pass...
bison 2.0 was released in jan 2006, and bison 2.1 in september 2005.
The current version of bison is 2.3 (released in june 2006).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: We're out of tree codes; now what?
Le Mon, Mar 19, 2007 at 05:41:08PM -0500, Gabriel Dos Reis écrivait/wrote:
> Nicholas Nethercote <[EMAIL PROTECTED]> writes:
>
> | On Mon, 19 Mar 2007, Doug Gregor wrote:
> |
> | >> > It's going to have a big performance impact. To extract a 9-bit value,
> | >> > the compiler will need to do a lot of masking every time it accesses
> | >> > the TREE_CODE.
> | >>
> | > So, about 16% slower with --enable-checking, 5% slower with
> | > --disable-checking.
> | >
> | > Subcodes might still be the way to go, but I'm feeling less bad about
> | > the 9-bit tree code option.
> |
> | As an interested outsider: GCC's compile-time speed has been
> | gradually decreasing for a while now. It seems to be acknowledged as
> | an undesirable thing, but not much has happened to change it. AIUI,
> | this is largely because it's very difficult. Nonetheless, seeing a 5%
> | slow-down caused by fixing a data structure design bogon is
> | disappointing.
>
> yeah, the trouble is that we don't seem to agree on what is good for
> long-term, or if and when we agree whether we would find and allocate
> resources to implement the solution. So, we end up accumulating
> small% regressions over small% regressions. Then we get busy with
> short-term fixes, because that is what gets the releases out the door.
> Until the next trouble.
I'm sorry to ask such a (probably naive) question, but do someone have a
precise idea of the performance strengths and weaknesses of GCC and of other
opensource compilers (like LLVM, Open64, TinyCC, ...) or even compiler for
different languages (SBCL, Haskell, SML, Java, ...). I don't have the big
picture of where is GCC strong - speaking about performance - (w.r.t. to
others compilers) and where is GCC weak.
Maybe a Wiki page on this might help, but I don't have any ideas on this.
Just thinking loud (maybe wrongly). And perhaps is it acceptable to lose
temporarily some performance, if we could hope to recover it later
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
why not use setjmp/longjmp within gcc?
Hello All
It seems to me that setjmp & longjmp are (almost) never used inside the
compiler but I don't understand why it is so.
It is quite standard since a long time, and I don't understand why it should
be avoided (as some old Changelog suggest).
gcc/doc/trouble.texi gives some hints about setjmp/longjmp but I don't
understand them as a requirement to not use it.
I'm probably misunderstanding something, could seom expert enlightezn me?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
example GCC plugins?
Hello list, Does the GCC community consider adding example plugins in the next release of GCC? I would be happy (and I could get funded to, e.g. by CHARIOT <https://www.chariotproject.eu/>) to contribute one (of course GPLv3+ licensed, and FSF copyrighted). But before really starting coding it, I need (in particular for funding organizations, notably H2020 <https://en.wikipedia.org/wiki/Framework_Programmes_for_Research_and_Technological_Development#Horizon_2020>) to have some assurance that my plugin might be incorporated in the next GCC release. (BTW, I was the GCC MELT <http://starynkevitch.net/Basile/gcc-melt/> guy, and actively contributed, with Jérémie Salvucci, to GCC plugin infrastructure) The plugin I have in mind would embed some Turing complete interpreter with sqlite <https://sqlite.org/> and JSONRPC <https://www.jsonrpc.org/> abilities or HTTPS REST abilities (I started clips-rules-gcc <https://github.com/bstarynk/clips-rules-gcc>, but I tend to believe that rewriting something from scratch, above GCC garbage collection, would be easier). This in relation with Bismon <https://github.com/bstarynk/bismon/> (a GPLv3+ software described here <http://starynkevitch.net/Basile/bismon-chariot-doc.pdf>). Funding agencies and employer won't allow me to code a plugin which has absolutely no change to be used. Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
static analysis above GCC (GSoC 2021)
On Fri, 2021-03-05 at 17:04 +0530, Ankur Saini via Gcc wrote: Hello, Hi Ankur While looking for some project to contribute on for GSOC 2021, I came across project about extending static analyser pass, especially the part that involve adding C++ support to it. You could look at the DECODER European project on https://www.decoder-project.eu/ and at the Bismon static source code analyzer funded by it (for a few more weeks) https://github.com/bstarynk/bismon Because of lack of funding, Bismon will probably be stopped in a few weeks. Cheers PS. My pet open source project is http://refpersys.org/ and I am seeking funding and applications for it. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
About porting GCC to backends which have a small number of registers. ....
To give just one small practical example, I'm told (by people who are more familiar with GCC internals than I) that it is not feasible with today's GCC to port to backends which have a small number of registers. I think (not sure) that could be attributed to j...@darrington.wattle.id.au - apologies if I am wrong. Why? GCC is doing many optimisations at the GIMPLE level. Why won't it be possible (even if very painful) to transform GIMPLE to some architecture with very few registers. IIRC, the TMS9900 (a microprocessor from texas instruments, in 1976) had very few hardware registers. One of them being a "pointer" to some "virtual register bank" on the call stack. http://www.bitsavers.org/components/ti/TMS9900/TMS_9900_Microprocessor_Data_Manual_May76.pdf I don't seen any impossibility in generating such instructions from GIMPLE. Of course, I am not candidate to do so... Cheers -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
mixing JIT and GCC (with a precompiled header?)?
Hello all,
Suppose that I have some header file in C myhead.h, containing notably
// Boehm's garbage collector, notably defines GC_malloc_atomic & GC_malloc
#include
struct myintvec_st {
unsigned vsiz; // allocated size
unsigned vlen; // used length, always <= vsiz
int varr[];
};
static inline struct myintvec_st*vec_alloc(unsigned siz) {
size_t fullsiz = sizeof(struct myintvec_st)+siz*sizeof(int));
struct myintvec_st* v = GC_malloc_atomic(fullsiz);
memset(v, 0, fullsiz);
v->vsiz = siz;
return v;
}
and many other struct declaration and static inline functions and extern
function declarations.
Now, I would like to use libgccjit with a context which contains all
the functions & structures from file myhead.h, in particular because I
want to JIT some calls to inlined static functions, and I expect the
gccjit to do the inlining (assuming I am using JIT with -O2 by calling
gcc_jit_context_set_int_option with
GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL to 2).
How is that possible? What should be done to make that possible?
I imagine that we might need a new function which initialize a
gcc_jit_context from a precompiled header...
Where should it go?
Regards.
--
Basile Starynkevitch http://starynkevitch.net/Basile/
configure --program-suffix could change gccjit library path?
Hello All, Imagine that someone (e.g. a distribution packager) wants to have several versions of gccjit like he does have several versions of gcc. Concretely, GCC 5.2 with GCC 6.1 I would believe that the --program-suffix argument of /configure would be useful. So he/she would compile GCC 5.2 with a --program-suffix=-5 argument to configure, and would like the gcc compiler to go in /usr/local/bin/gcc-5 and the GCCJIT library to go in /usr/local/lib/libgccjit-5.so, so users of GCCJIT 5.1 would link with -lgccjit-5 And he/she would also compiile GCC 6.1 with a --program-suffix=-6 argument to configure and would like the gcc compiler to go in /usr/local/bin/gcc-6 and the GCCJIT library to go in /usr/local/lib/libgccjit-6.so so users ofg GCCJIT 6.1 woudl link with -lgccjit-6 Having two different GCCJIT libraries is IMHO a legitimate wish (likewise, one can easily have several versions of LLVM libraries on Debian). AFAIU, the --program-suffix is not yet understood by GCCJIT configuration things. This is a wish, since I don't know autoconf well enough to be able to propose any patch. Or perhaps there is some existing configure switch already related to location of libgccjit? Regards. -- Basile Starynkevitch http://starynkevitch.net/Basile/ France
GCC/JIT and precise garbage collection support?
Hello All,
(this is triggered by a question on the Ocaml mailing list asking about
SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
GCCJIT)
We might want to support better good garbage collection schemes in GCC,
particularily in GCCJIT. This is a
thing that LLVM is known to be weak at, and we might aim to do much
better. If we did, good frontends for
good functional languages (e.g. F#, Ocaml, Haskell) might in the future
profit of GCC technology. And even a Javascript engine based on GCCJIT
could profit.
A good GC is very probably a precise (sometimes generational copying) GC
with write barriers
(read the http://gchandbook.org/ for more, or at least the wikipage
about garbage collection). So a good GC is changing pointers.
So we need to know where, and provide a mechanism for, pointer values
are located in the call stack (of the GCCJIT generated code), and
probably provide some write barrier machinery.
In my incomplete understanding, this requires cooperation between GCC
backend and middle-end; it perhaps mean in the GIMPLE level that we mark
some trees for local variables as been required to be spilled (by the
backend) at some well defined location in the call frame, and be able to
query that location (i.e. its offset).
Perhaps a possible approach might be to add, at the C front-end level,
an extra variable attribute telling that the variable should be spilled
always at the same offset in the call frame, to have some machinery to
query the value of that fixed offset, and to also have a GCC builtin
which flushes all the registers into the call frame?
This is just food for thoughts and still fuzzy in my head. Comments are
welcome (including things like we should not care at all about GC).
Notice that if we had such support for garbage collection, the (dying)
Java front-end could be resurrected to provide a faster GC than Boehm
GC. And GCC based compilers for languages like Go or D which have
garbage collection could also profit. (even MELT might take advantage of
that).
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 mine, sont seulement les miennes} ***
magic 8 constant (bits / byte maybe?) in GCC JIT memento_of_new_rvalue_from_const ::get_wide_int
Hello All,
In GCC trunk svn 225726 the file gcc/jit/jit-recording.c contains the
following code near line 4168:
/* The get_wide_int specialization for . */
template <>
bool
memento_of_new_rvalue_from_const ::get_wide_int (wide_int *out) const
{
*out = wi::shwi (m_value, sizeof (m_value) * 8);
return true;
}
I am guessing that the magic constant 8 above (i.e. line 4170) is the
bits per char on the host machine, but I am not entirely sure of that.
(Maybe it is the bits per char on the target, but I guess not)
Is my understanding correct?
Do we care about running GCCJIT on weird host machines where char is
not a 8 bit byte?
Do we care abour running GCCJIT for cross-compilation to weird target
machines where char is not a 8 bits byte?
Out of curiosity, what are today the systems for which GCC is hosted,
or is targetted, on something where char are not an 8 bits byte?
Regards.
--
Basile Starynkevitch http://starynkevitch.net/Basile/
France
Ann: MELT plugin 1.2.0 for GCC 4.9 & 5.
Hello All, It is my pleasure to announce the MELT plugin 1.2.0 for GCC 4.9 & GCC 5. MELT is a domain specific language to extend or customize the GCC http://gcc.gnu.org/ compiler. See http://gcc-melt.org/ for more about MELT. It is implemented as a GCC plugin, FSF copyrighted and GPLv3+ licensed. The MELT plugin 1.2.0 release (for GCC GCC 4.9 or GCC 5.*) is available (since july 24th, 2015) from http://gcc-melt.org/melt-1.2.0-plugin-for-gcc-4.9-or-5.tar.bz2 as a bzip2-ed tar source file of md5sum e718e8686a947f801d7fba4f3e699f80, and of 4075486 bytes (4.0 Megabytes), extracted from MELT branch svn revision 226151.. It brings significant features and bug fixes. Please upgrade. Notice that some packaged versions of GCC 5 on some Linux distributions (some versions of Debian) has a bug affecting MELT. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793478 You might need to upgrade your package, or fix it by editing the plugin-version.h of that package. Its GCCPLUGIN_VERSION_MINOR is incorrect. NEWS for 1.2 MELT plugin for GCC 4.9 and 5.x [[july 24th, 2015]] Bug fixes = More verbose messages about quote with more than one argument. Language features = The _MELT_FILE_ and _MELT_LINE_ identifiers are not symbols, but expanded to the file name and line number; this is probably a discutable feature, better use (this_file) and (this_line) macros... Runtime features Ported to GCC 4.9 & GCC 5.x types. ### Please report bugs to gcc-m...@googlegroups.com Regards. -- Basile Starynkevitch http://starynkevitch.net/Basile/ Francebasile starynkevitch.net working on http://gcc-melt.org/ Opinions are only mine!
gengtype: missing `tag' option (MELT branch)
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch (svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
gengtype write #1 gt-go-go-lang.h
gengtype write #2 gt-jit-dummy-frontend.h
gengtype write #3 gt-c-c-decl.h
gengtype write #4 gt-cp-tree.h
gengtype write #5 gt-fortran-f95-lang.h
gengtype write #6 gtype-desc.c
gengtype write #7 gtype-lto.h
gengtype write #8 gtype-java.h
gengtype write #9 gtype-ada.h
gengtype write #10 gtype-desc.h
gengtype wrote 10 files.
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
FWIW, the gcc/melt/generated/meltrunsup.h file did not change in the
MELT branch since long time ago.
Do you have any clues about what has changed in gengtype about these tag
options in GCC 6? Or about the gimple type?
Regards.
PS. Of course the bug is very probably in the MELT branch, but it has
been a long time since I dived into gengtype. I can't figure out the error.
--
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: gengtype: missing `tag' option (MELT branch)
On 02/11/16 23:13, David Malcolm wrote:
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch
(svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch
any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
`tag'
option for type `gimple'
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
In r227941, "gimple" changed meaning. It's no longer a pointer to a
statement; instead, it's now the statement struct itself (see e.g.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00765.html )
Try changing these to "gimple *".
That surely helps a lot. My feeling is that such a drastic change might
justify a comment in gcc/coretypes.h (for those porting a plugin from
GCC 5 to newer versions of GCC)
Thanks, 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 mine, sont seulement les miennes} ***
gengtype: conditional GTY ? (to add before GCC 6 release)
Hello All,
This is motivated by MELT, but I believe it would be useful to every GCC
plugin which tries to be
compilable both for GCC 5 & GCC 6.
The technical issue described in
https://gcc.gnu.org/ml/gcc/2016-02/msg00149.html is that the gimple
identifier in plugins has changed from pointer (in GCC 5 and earlier) to
class.
I feel that is a very major change w.r.t. plugins. Most (and probably
all) GCC plugins will be affected.
(A cosmetic patch might be to name gimpleinstance what is today gimple)
A tempting way might be
#if GCCPLUGIN_VERSION >= 6000
typedef gimple* melt_gimpleptr_t;
#else
typedef gimple melt_gimpleptr_t;
#endif /* GCC 6 */
unfortunately, that does not work today, because gengtype does not get
preprocessed input (and does not invoke the preprocessor).
Perhaps we should consider patching gengtype to enable conditional GTY-s
at least for typedefs.
I am tempted to try implementing a conditional GTY, perhaps
typedef GTY((when(WANTPOINTER)) gimple* melt_gimpleptr_t;
and
typedef GTY((unless(WANTPOINTER)) gimple melt_gimpleptr_t;
then, add a condition argument to gengtype processor, perhaps invoking
it as
gengtype -CWANTPOINTER
or
gengtype --condition WANTPOINTER
but this makes sense only if such a gengtype patch would go both into
GCC 6 and into the next microrelease of GCC 5, i.e. GCC 5.4
I'm afraid that the current stage rules forbid that. Or, could such a
patch be considered as a bug fix?
Opinions are welcome!
Regards.
PS. The very dirty alternative would be to feed gengtype with different
variants of inputs. That is ugly.
--
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: gengtype: conditional GTY ? (to add before GCC 6 release)
On 02/12/16 14:38, Richard Biener wrote:
On Fri, Feb 12, 2016 at 1:23 PM, Basile Starynkevitch
wrote:
I am tempted to try implementing a conditional GTY,
[...]
but this makes sense only if such a gengtype patch would go both into GCC 6
and into the next microrelease of GCC 5, i.e. GCC 5.4
I'm afraid that the current stage rules forbid that. Or, could such a patch
be considered as a bug fix?
Sorry, no.
I was afraid (but I am not surprised) of such a reply.
So won't spend any additional minute on patching gengtype.
So I will have to generate some additional file in MELT (containing
simply the
typedef gimple* melt_gimpleptr_t;
line) and hack the build procedure.
The plugin API was never considered stable and thus plugins have to
deal with incompatibilites as they arise.
Help with picking up the partially completed work on a stable plugin
(introspection) API
is of course welcome.
What exact functions (their name, the source files defining them) in the
current GCC trunk are you referring to by your "introspection" word?
Last time I checked (a few months ago) there where nothing related to
that. Today, the only occurrences of introspection (in GCC trunk svn
rev233268) are in Java part and in the libsanitizer.
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 mine, sont seulement les miennes} ***
stable plugin introspection API ... Where?
Dear all
In https://gcc.gnu.org/ml/gcc/2016-02/msg00157.html
Richard Biener (richard dot guenther at gmail dot com) is mentioning:
Help with picking up the partially completed work on a stable plugin
(introspection) API is of course welcome.
Can anyone explain me what and where is that stable plugin introspection
API?
In https://gcc.gnu.org/ml/gcc/2016-02/msg00159.html I (Basile) wrote:
> What exact functions (their name, the source files defining them) in
the current GCC trunk
> are you referring to by your "introspection" word? Last time I
checked (a few months ago)
> there where nothing related to that. Today, the only occurrences of
introspection
> (in GCC trunk svn rev233268) are in Java part and in the libsanitizer.
FWIW, Richard Beiner did not had time or wish to answer to that
(I've got no answer neither privately nor on the list).
So I am rephrasing my question:
which functions and source files are relevant today in the trunk for a "stable
plugin introspection API"?
I did try to find something related, but my search is completely unsuccessful
yet.
My feeling (and I really hope to be wrong, because any reflective or
introspective
ability in GCC would help my work in the MELT plugin, see http://gcc-melt.org/
for more, a big lot)
is that today there is no plugin-related introspection API at all in GCC. It
still
looks today (february 20165) as a wish or some vaporware.
I still hope to be very wrong, but then please enlighten me by naming the
actual functions and source files
related to the plugin introspection API. Or give me some source files and line
numbers
(in the GCC trunk, i.e. future GCC 6, of february 2016) if you like so.
Since I am not a native English speaker, I am referring to:
https://en.wikipedia.org/wiki/Type_introspection
https://en.wikipedia.org/wiki/Reflection_%28computer_programming%29
https://en.wikipedia.org/wiki/Homoiconicity
https://en.wikipedia.org/wiki/Metadata
https://en.wikipedia.org/wiki/Metaclass
(BTW, MELT does have some of these, but they are currently for MELT specific
features,
not yet for general GCC ones; this means that I -Basile- value & cherish these
features
a lot and I am hungry
to have them inside GCC)
So it looks like Richard see a "partially completed work" on "plugin introspection
API"
while I (Basile) don't see even the smallest start about it (or even consensus
about wishing that).
I hope to be wrong, so please point me some actual piece of code related to
that in GCC 6.
FWIW, it is possible for some C++ program to have some metadata. Qt is a
concrete example.
http://doc.qt.io/qt-5/metaobjects.html;
GTK is explicitly mentioning Introspection in
https://wiki.gnome.org/Projects/GObjectIntrospection
but I don't see anything remotely related to such things inside GCC.
AFAIU, we don't have any programmatic way to query the GCC API useful in
plugins today.
So please help me finding some related features in current GCC 6 (trunk) code
base (in February 2016).
I'm sure that most plugin writers would be pleased to know about that.
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 mine, sont seulement les miennes} ***
Ann: MELT plugin 1.3 release candidate 1 for GCC 5 or GCC 6
Hello All,
It is my pleasure to announce the MELT plugin 1.3 release candidate 1
for GCC 5 & GCC 6
(hosted on Linux preferably).
MELT -see http://gcc-melt.org/ for more (or
http://starynkevitch.net/Basile/gcc-melt/ which points to the same web
pages and resources) - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
Please download the bzip2 compress source tar archive from
http://gcc-melt.org/melt-plugin-1.3-rc1-for-gcc-5-or-6.tar.bz2
It is a file of 4003571 bytes (3.9Mb) and md5sum
85f21dd54b896bce71678951f1e812ec
NEWS for 1.3 MELT plugin for GCC 5 & GCC 6
[[may XX, 2016]]
Bug fixes
=
Rare garbage collection bug fixed (noticed with GCC 5).
Language features
=
No significant new language feature.
Runtime features
We did keep compatibility with GCC 5 & GCC 6.
Since gengtype does not admit conditionals (see messages following
https://gcc.gnu.org/ml/gcc/2016-02/msg00156.html ...) we had to hack
our build system. The MELT plugin now use some melt-runtypes.h
symlink to a version specific file, which has typedef-s like
typedef gimple* melt_gimpleptr_t; // gimple is now a struct
Please try to build & use that release candidate and report bugs to
gcc-m...@googlegroups.com
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 mine, sont seulement les miennes} ***
Ann: MELT plugin 1.3 release candidate 2 for GCC 5 or GCC 6
Dear All,
It is my pleasure to announce the MELT plugin 1.3 release candidate 2
for GCC 5 & GCC 6
(hosted and usable on Linux preferably).
MELT -see http://gcc-melt.org/ for more (or
http://starynkevitch.net/Basile/gcc-melt/ which points to the same web
pages and resources) - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
Please download the bzip2 compress source tar archive from
http://gcc-melt.org/melt-1.3-rc2-plugin-for-gcc-5-or-6.tar.bz2
It is a file of 4013849 bytes (3.9Mbytes) and md5sum
eb4df214b293caabec07be4a672eda4e
NEWS for 1.3 MELT plugin for GCC 5 & GCC 6
[[may XX, 2016]]
Bug fixes
=
Rare garbage collection bug fixed (noticed with GCC 5).
Language features
=
No significant new language feature.
Runtime features
We did keep compatibility with GCC 5 & GCC 6.
Since gengtype does not admit conditionals (see messages following
https://gcc.gnu.org/ml/gcc/2016-02/msg00156.html ...) we had to hack
our build system. The MELT plugin now use some melt-runtypes.h
symlink to a version specific file, which has typedef-s like
typedef gimple* melt_gimpleptr_t; // gimple is now a struct
Added plugin options:
-fplugin-melt-arg-verbose-full-gc: if set to 1 or Y, a message is
output to stderr on MELT full garbage collections.
-fplugin-melt-arg-mmap-reserve: don't use it, except to debug the
MELT runtime. See comment in melt-runtime.cc
The MELT runtime (that it the MELT plugin melt.so) could be built with
-DMELT_HAVE_RUNTIME_DEBUG=1 to enable MELT runtime debugging. This is
rarely useful for MELT users.
w.r.t. MELT plugin 1.3 rc1 I have made a few bug fixes (including
perhaps some annoying GC bug that I cannot reproduce anymore).
Please try to build & use that release candidate 2 and report bugs to
gcc-m...@googlegroups.com
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 mine, sont seulement les miennes} ***
Re: True "no-exceptions" mode?
On Sun, 2014-05-18 at 12:33 -0300, Daniel Gutson wrote:
> Hi,
>
>I am needing a truly exceptions-clean (or exceptions-free) binary due to
> some embedding systems platform.
> -fno-exceptions is not enough of course.
Did you think of making some extension (using MELT, see
http://gcc-melt.org/ for more) or some plugin (in C++) which would
at least check that no exception gimple is going thru.
This might be adding a pass which would detect and bark when
exception-related gimples are used.
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 mine, sont seulement les miennes} ***
Re: Roadmap for 4.9.1, 4.10.0 and onwards?
On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
> Hi,
> I've been tracking the latest releases of gcc since 4.7 or so (variously
> interested in C++1y support, cilk and openmp).
> One thing I've found hard to locate is information about planned inclusions
> for future releases.
> As much relies on unpredictable community contributions I don't expect there
> to be a concrete or reliable plan.
> However, equally I'm sure the steering committee have some ideas over what
> ought
> to be upcoming releases.
As a whole, the steering committee does not have any idea, because GCC
development is based upon volunteer contributions.
However, some members of the steering committee might work in large
organization having a team of GCC contributors. That team might have its
own (private) agenda. But every patch has to be approved by someone
else.
So I don't think that the steering committee knows a lot more than you
and me.
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 mine, sont seulement les miennes} ***
Re: How can I get started as a GCC developer
On Tue, Jun 10, 2014 at 06:30:54PM +0800, Anonymous User wrote:
I'm not sure that being anonymous is helpful on GCC
(and it might even be frowned upon, but I don't want to start a flamewar) I
think that you need and you want
to be identified. Besides, working on GCC is difficult; you'll soon be proud of
being able
to work on it, and that also wants you to be identified.
You surely need to start with legal stuff. They take time (perhaps months, and
surely weeks!).
Read carefully http://gcc.gnu.org/contribute.html#legal
Once all is done and signed (both by FSF and you or your employer), add your
real name in MAINTAINERS file.
>
> So how can I gain a systematic understanding of the internals of GCC in
> order to get started with some serious work?
I'm definitely biaised, but I suggest first to be able to write some GCC
plugins
(or some MELT extensions, see http://gcc-melt.org/ for more).
Read in particular my latest slides
http://gcc-melt.org/gcc-plugin-MELT-LinuxCollabSummit2014.pdf
(GCC plugins thru the MELT examples). They give a lot of pointers.
Don't forget to read http://www.cse.iitb.ac.in/grc/
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} ***
Re: Gcc plugin for modification of source code ?
On Sun, 2014-06-15 at 02:40 +0530, Mohsin Khan wrote:
> Hi,
> I'm working on a gcc plugin project. I had a doubt, can somebody help
> me on this.
[no need to ask on gcc-help@; plugins are definitely gcc internals
related and should better be discussed on gcc@gcc.gnu.org]
> Can we write a plugin (which works after a pass like cfg or any other)
> which can modify the source code of .C file, for example insert
> comments before function definitions or insert a new IF Block in the
> .C file. And after modification it writes the entire modified code to
> a new .C file. Is this type of plugin possible in GCC. If yes, please
> tell me how and if No, please tell me why.
If your source file does not contain any #line directive, a GCC plugin
(or a MELT extension, see http://gcc-melt.org/ for more) is able to get
the source code position of every Gimple instruction. (But did you think
about instruction obtained by some macro expansions?).
With that information, you can indeed transform the C source as you
wish. It might not be simple (you need to build an editor-like internal
represention of each line of the source code).
However, modifying the Gimple representation (without modifying any C++
source file) is probably simpler.
What exactly do you want to achieve? Are you sure that a source to
source transformation is worthwhile -given that you can transform
internal GCC representations like Gimples-?
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 mine, sont seulement les miennes} ***
ICE with atomic_store
Hello All,
The following code:
#include
struct s1_st {
char* i_name;
struct s1_st* i_foo;
};
void clear_s1 (struct s1_st*s)
{
__atomic_store(s->i_name, NULL, __ATOMIC_SEQ_CST);
}
gives an ICE when compiled (on Debian/Sid/amd64) by GCC 4.8 & 4.9 (I did not
test it on the trunk yet)
(For some strange reason, probably on my side, I'm not able to change the
password on bugzilla. So I'm reporting that bug here, sorry for the
inconvenience).
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} ***
Ann: MELT plugin 1.1 release candidate 1 available
Dear All,
It is my please to announce the MELT plugin 1.1 release candidate 1 for
GCC 4.8 and 4.9 (hosted preferably on Linux).
MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
The MELT plugin 1.1 release candidate 1 (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 26th,
2014) from
http://gcc-melt.org/melt-1.1-rc1-plugin-for-gcc-4.8-or-4.9.tar.bz2
as a bzip2-ed tar source file of md5sum
3b7ea46dddac2e81927c211ca6a90201, and of 3891814 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 213071.
NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).
End-user improvements
=
***
The module list files *.modlis accept conditioned extra
modules. Within them, a line like
?findgimple xtramelt-ana-simple.optimized
means that: if the mode is findgimple, load the xtramelt-ana-simple
module in its optimized flavour.
The predefined modules now are named libmelt*.melt for standard
library modules and xtramelt*.melt for extra modules.
Language improvements
=
Add support for JSON (parsing and emitting JSON format) and
JSONRPC2 client with TCP/IP transport. See
DO_BLOCKING_JSONRPC2_CALL, MAKE_JSON_PARSER, OUTPUT_JSON, etc...
This requires an UTF-8 locale.
***
Several bug fixes, notably MELT-SFT-8. Better variadic binding.
Many small improvements.
***
The MODULE_IS_GPL_COMPATIBLE directive is now required to avoid
warnings. Your modules should be GPL compatible, and state that with
a directive like
(MODULE_IS_GPL_COMPATIBLE )
for example
(MODULE_IS_GPL_COMPATIBLE "GPLv3")
Runtime improvements
***
The old GTKmm (or Qt/Python) probe is becoming deprecated. A
partial support for JSON & JsonRpc2 client is available. A
web-based MELT monitor is in the works, but not yet released.
***
Input channel handlers can be either paragraph oriented (like in
previous MELT releases) or raw input.
***
We don't use setjmp but C++ exceptions
***
melt_walk_use_def_chains adapted for GCC 4.9, and compatibility with
GCC 4.9
***
The successful modes list is printed.
***
Nearly systematic use of hooks.
***
Improved support of pragmas, with both REGISTER_EXPANDED_PRAGMA &
REGISTER_PLAIN_PRAGMA function.
***
Sorting primitives like multiple_sort are fully reentrant, so their
compare routine might do a sort itself!
***
Remove old option handling, REGISTER_OPTION is removed.
Bug and success reports are welcome on gcc-m...@googlegroups.com
(If I get no annoying critical bug report, I will release MELT plugin
1.1 in the next few days)
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 mine, sont seulement les miennes} ***
Ann: MELT plugin 1.1 release available for GCC 4.8 & 4.9
Dear All,
It is my pleasure to announce the MELT plugin 1.1 release for GCC 4.8 &
4.9 (hosted preferably on Linux). I've corrected all the bugs found in
MELT 1.1rc1.
MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
The MELT plugin 1.1 release (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 27th,
2014) from
http://gcc-melt.org/melt-1.1-plugin-for-gcc-4.8-or-4.9.tar.bz2
This is a bzipped2 source tar archive of 3891501 bytes (3.8 Mbytes) of
md5sum dcd4332f91140f12bee51ae4d33f66f0
This MELT 1.1 plugin is extracted from the GCC MELT branch svn revision
213094
NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 27th, 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).
End-user improvements
=
***
The module list files *.modlis accept conditioned extra
modules. Within them, a line like
?findgimple xtramelt-ana-simple.optimized
means that: if the mode is findgimple, load the xtramelt-ana-simple
module in its optimized flavour.
The predefined modules now are named libmelt*.melt for standard
library modules and xtramelt*.melt for extra modules.
Language improvements
=
Add support for JSON (parsing and emitting JSON format) and
JSONRPC2 client with TCP/IP transport. See
DO_BLOCKING_JSONRPC2_CALL, MAKE_JSON_PARSER, OUTPUT_JSON, etc...
This requires an UTF-8 locale.
***
Several bug fixes, notably MELT-SFT-8. Better variadic binding.
Many small improvements.
***
The MODULE_IS_GPL_COMPATIBLE directive is now required to avoid
warnings. Your modules should be GPL compatible, and state that with
a directive like
(MODULE_IS_GPL_COMPATIBLE )
for example
(MODULE_IS_GPL_COMPATIBLE "GPLv3")
Runtime improvements
***
The old GTKmm (or Qt/Python) probe is becoming deprecated. A
partial support for JSON & JsonRpc2 client is available. A
web-based MELT monitor is in the works, but not yet released.
***
Input channel handlers can be either paragraph oriented (like in
previous MELT releases) or raw input.
***
We don't use setjmp but C++ exceptions
***
melt_walk_use_def_chains adapted for GCC 4.9, and compatibility with
GCC 4.9
***
The successful modes list is printed.
***
Nearly systematic use of hooks.
***
Improved support of pragmas, with both REGISTER_EXPANDED_PRAGMA &
REGISTER_PLAIN_PRAGMA function.
***
Sorting primitives like multiple_sort are fully reentrant, so their
compare routine might do a sort itself!
***
Remove old option handling, REGISTER_OPTION is removed.
Bug and success reports are welcome on gcc-m...@googlegroups.com
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 mine, sont seulement les miennes} ***
Ann: MELT 1.1.1 plugin for GCC 4.8 & 4.9
It is my pleasure to announce the MELT 1.1.1 plugin for GCC 4.8 and 4.9 The MELT plugin 1.1.1 release (for GCC 4.8 or 4.9) is available (since august 11th, 2014) from http://gcc-melt.org/melt-1.1.1-plugin-for-gcc-4.8-or-4.9.tar.bz2 as a bzip2-ed tar source file of md5sum 5879dd6931d169bb64384b33537624e2, and of 3899914 bytes (3.8 Megabytes), extracted from MELT branch svn revision 213809. It brings bug fixes with respect to MELT 1.1 (so you should upgrade). NEWS for 1.1.1 MELT plugin for GCC 4.8 & 4.9 [[august, 11th, 2014]] Bug-fix release w.r.t. to MELT plugin 1.1 Bug fixes = connect_to_server works better for AF_UNIX socket. JSONRPC works better. double boxed and unboxed data works. pragma works better. Users of MELT 1.1 are invited to upgrade. Regards -- Basile Starynkevitch http://starynkevitch.net/Basile Opinions are mine only!
consistent naming of passes....
Hello all,
When I compile some file (precisely, the gcc/melt-runtime.cc from the latest
melt branch) with -O1 -fdump-passes (using GCC 4.9) I'm getting
notably
ipa-cp : OFF
ipa-cdtor : OFF
ipa-inline : ON
ipa-pure-const : ON
ipa-static-var : ON
ipa-pta : OFF
ipa-simdclone : OFF
*free_cfg_annotations : ON
However, in file gcc/ipa-inline.c there is
const pass_data pass_data_ipa_inline =
{
IPA_PASS, /* type */
"inline", /* name */
OPTGROUP_INLINE, /* optinfo_flags */
false, /* has_gate */
true, /* has_execute */
TV_IPA_INLINING, /* tv_id */
I find strange that the two names (the one given by -fdump-passes and the one
in the pass_data_ipa_inline object) are different.
When I try to insert a plugin pass (actually in MELT, file
gcc/melt/xtramelt-ana-simple.melt) named "inline" it gives:
cc1plus: fatal error: pass 'inline' not found but is referenced by new pass
'melt_justcountipa'
If I use "ipa-inline" I'm getting
cc1plus: fatal error: pass 'ipa-inline' not found but is referenced by new pass
'melt_justcountipa'
How should a plugin writer find the name of the reference pass to insert his
own new pass? At the very least it should be documented, and preferably it
should be identical to output of -fdump-passes
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 mine, sont seulement les miennes} ***
GCC plugins & GGC & explicit gcc_free
d be replaced by a call to
ggc_becomes_freeable which for example would call ggc_free if not plugin
is loaded, and stays a no-op if some plugins are loaded...).
Perhaps we could improve the situation e.g.
document more when and which data is cleaned up
add a finalizer plugin hook for the few static calls to ggc_free, but
that probably would be quite expensive (e.g. we'll run that hook from
free_edge in gcc/cfg.c ...) because ggc_free is probably called a big
lot of times.
more realistically, add plugin hooks in cleanup routines, notably in
cleanup_cfg file gcc/cfgcleanup.c
Please comment on this. If we agree on something I'll try to propose
some patch to GCC 5.0 during its stage 1.
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 mine, sont seulement les miennes} ***
Re: GCC plugins & GGC & explicit gcc_free
On Fri, 2014-08-29 at 19:58 +0200, Richard Biener wrote:
>
> You are in the same situation as any other pass would be. Don't hang on
> things that can get stale.
>
> There is no point in keeping a pointer to a deleted edge.
Yes there is. The use case is to make some statistics on edges and to
print these at FINISH_UNIT time.
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 mine, sont seulement les miennes} ***
Ann: MELT 1.1.2 plugin for GCC 4.8 & 4.9 release (bugfixes)
Dear All,
It is my pleasure to announce the MELT 1.1.2 plugin for GCC 4.8 & 4.9.
MELT -see http://gcc-melt.org/ for more- is a domain specific language
to extend GCC, and a GCC plugin (free software, GPLv3 licensed, FSF
copyrighted).
This (mostly bug-fixing) release is available from
http://gcc-melt.org/melt-1.1.2-plugin-for-gcc-4.8-or-4.9.tar.bz2
as a bzip2-ed tar source file of md5sum
fab80bfaee76abea1513c69f504ab49f, and of 3936275 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 214717. It brings bug fixes with
respect to MELT 1.1.1 (so you should upgrade).
Bug fixes
=
Better plugin build (ending message mention that probe is obsolete)
All passes data are cleared in hook_all_passes_end.
Gives an error message for unknown mode.
Reject loading twice the same MELT module.
register_pre_genericize_first & register_pre_genericize_last
should work.
mixbigint-s are understood by output_json.
assert_msg don't loop with non-value arguments.
do_blocking_jsonrpc2_call returns secondarily the time in
milliseconds needed to process the JSONRPC call.
register_gcc_attribute works, and is a macro.
tree_chain_to_tuple is a new function.
#
Please ask questions and give feedback (successes or bug reports) on
gcc-m...@googlegroups.com list.
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 mine, sont seulement les miennes} ***
Ann: MELT plugin 1.1.3 for GCC 4.8 & 4.9
Dear All,
It is my pleasure to announce the MELT plugin 1.1.3 for GCC 4.8 or 4.9
MELT is a high-level domain specific language and plugin to customize
GCC, see http://gcc-melt.org/ for details.
It is free software, GPLv3+ licensed, FSF copyrighted.
You can download the source tarball from
http://gcc-melt.org/melt-plugin-1.1.3-for-gcc-4.8-or-4.9.tar.bz2
this is a bzip2-ed tarball of 4124848 bytes (4.0Mbytes) extracted from
the GCC MELT branch svn rev. 217521 on november 13th, 2014
It brings several new features and significant bug fixes w.r.t. previous
MELT 1.1.2 (of august 31st 2014)
NEWS for 1.1.3 MELT plugin for GCC 4.8 & 4.9
[[november 13th, 2014]]
Bug-fix & feature-increase with significant improvements release
w.r.t. to MELT plugin 1.1.2.
Bug fixes
=
Better working macros, and improved documentations
Language improvement
Improved macro constructs.
All common (i.e. non-language specific) tree codes are handled, at
least thru an automatically generated cmatcher.
All non-OMP gimple codes are handled.
Better handling of variadic tree & gimple constructs.
Added gimple_call_args & gimple_call_more_args quasi-cmatcher,
gimple_switch handling, and functions to build them with a MELT
sequence (tuple or list) of constituents.
Variadic and polytypic add2list.
End-user improvements
=
Better eval mode. More informative error messages.
Documentation generated in several HTML files.
###
Please report bugs and comments to gcc-m...@googlegroups.com
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 mine, sont seulement les miennes} ***
FOSDEM talk on GCC MELT (Lisp devroom)
Hello All
(sorry for the self-promotion)
I'm giving tomorrow january 31st 2015, at FOSDEM2015 (Lisp Dev Room) an
hour talk about GCC MELT
MELT is a Lispy domain specific language (implemented as a
GPLv3+licensed, FSF copyrighted, meta-plugin for GCC) to extend and
customize the GCC compiler.
About the GCC compiler, see http://gcc.gnu.org/
About MELT, see http://gcc-melt.org/
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 mine, sont seulement les miennes} ***
Re: Warning for C Parameter Name Mismatch
(I am reading the GCC mailing list in digest mode)
On 3/9/19 10:58 PM, gcc-digest-h...@gcc.gnu.org wrote:
On Fri, 8 Mar 2019, Joel Sherrill wrote:
Can gcc report when the parameter name in a C prototype
does not match that used in the implementation?
int f(int x);
int f(int y) {...}
I think this would be normal and expected - an installed header would use
a reserved-namespace name for the parameter while the implementation uses
a non-reserved name that's more convenient for use within the
implementation. (Thus anything like this would only be useful if it can
know that it's e.g. OK to have __y and y as the names, and some code no
doubt uses other such conventions relating the two names.)
I can appreciate that a warning like this is not for everyone. But
/I/ would like and use such a warning for my own code.
May I remind to all that this is a typical case for you writing a GCC
plugin. You want a warning that few other people want, and that warning
is tied to your particular coding style.
You could avoid that warning by avoid naming the parameters in your
header files, so you would declare
int f (int /*x*/); in your header file.
You might want to get a warning, but since it is not of general use (as
many explained, not using the same name in the header and in the
implementation of a given function parameter makes a lot of sense in
general, even if you dislike such as style) you really should consider
writing your own GCC plugin for that purpose.
How to write such a GCC plugin is a different question, and should be
asked as such.
Cheers.
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
Re: Warning for C Parameter Name Mismatch
On 3/10/19 12:54 PM, David Brown wrote:
On 10/03/2019 07:11, Basile Starynkevitch wrote:
(I am reading the GCC mailing list in digest mode)
On 3/9/19 10:58 PM, gcc-digest-h...@gcc.gnu.org wrote:
On Fri, 8 Mar 2019, Joel Sherrill wrote:
Can gcc report when the parameter name in a C prototype
does not match that used in the implementation?
int f(int x);
int f(int y) {...}
I think this would be normal and expected - an installed header
would use
a reserved-namespace name for the parameter while the implementation
uses
a non-reserved name that's more convenient for use within the
implementation. (Thus anything like this would only be useful if it
can
know that it's e.g. OK to have __y and y as the names, and some code no
doubt uses other such conventions relating the two names.)
I can appreciate that a warning like this is not for everyone. But
/I/ would like and use such a warning for my own code.
May I remind to all that this is a typical case for you writing a GCC
plugin. You want a warning that few other people want, and that
warning is tied to your particular coding style.
You could avoid that warning by avoid naming the parameters in your
header files, so you would declare
int f (int /*x*/); in your header file.
You might want to get a warning, but since it is not of general use
(as many explained, not using the same name in the header and in the
implementation of a given function parameter makes a lot of sense in
general, even if you dislike such as style) you really should
consider writing your own GCC plugin for that purpose.
How to write such a GCC plugin is a different question, and should be
asked as such.
Cheers.
I fully agree that this is not a warning everyone will want - but I
disagree with the idea that it is a specialist or unusual warning.
Remember, no one is asking for it to be in -Wall or -Wextra. gcc has
many, many warnings available, and a large proportion of them will
only be useful to a small proportion of users. You could certainly
say that of things like "-Wmissing-prototypes",
"-Wmissing-declarations" and "-Wredundant-decls". I fail to see that
this suggestion is at all different.
In particular, I see this warning being of little use for large C /
C++ applications with code split into multiple libraries. But I see
it as being of a good deal of use in small-systems embedded
programming where you have a smaller code base, all compiled together
in one project, and where coding conventions and styles are often
strict. That will apply to only a very small proportion of people
programming for x86-64 targets - but a very high proportion of those
programming for AVR, msp430, ARM Cortex-M, and most of the other
targets of gcc. It is easy to forget or underestimate the huge range
of types of programming done with gcc - there are many of us for whom
warnings like this would be a useful tool.
However, you are right that plugins could be a way to achieve this. I
think the Python plugin could be a good way to prototype features like
this - and if it is useful, then it could be moved into gcc main.
In the long term, the question becomes philosophical. I would be really
happy if every future GCC release would come with a small set of
"example" plugins for various unusual warnings. And I even think that
such an approach will favor outside people to write plugins for their needs.
I am not so sure that making an even larger cc1plus binary is wanted.
Of course, I am making the hypothesis that plugins are as necessary as
directories to host GCC.
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
GCC 8: adding, thru a plugin, an analyzing RTL pass after pro_and_epilogue issue with its reference_pass_name
Hello All, This is work done for the CHARIOT H2020 project (see https://www.chariotproject.eu/ for more context) in relation with my BISMON project (see http://github.com/bstarynk/bismon/ for more, and, if you want more context, read the draft report on http://starynkevitch.net/Basile/bismon-chariot-doc.pdf but skip the few first pages for H2020 managers). I have to make a preliminary proof-of-concept that my BISMON project could be useful, with some ad-hoc GCC 8.3 plugin, to compute a crude approximation of the call stack of a tiny freestanding kernel (for x86 in 32 bits, so compiled with: gcc-8 -ffreestanding -m32 -O2 -Wall -fstack-usage and my plugin). I am working right now on that hand-written GCC 8.3 plugin. It inserts two GCC passes, and both passes are only analyzing passes (they don't change a single bit of GIMPLE or RTL representations). The first pass, named chariot_callgraph, is (oversimplifying) printing the call graph (and I will improve later that pass to communicate with BISMON). It is a pass of kind GIMPLE_PASS successfully inserted after the reference_pass_name "sra" and it works well enough. The second pass, named chariot_framesize, is (oversimplifying) expected to run with the printing the call frame size (and I will improve later that pass to communicate with BISMON). I want to insert that second pass following this explanation (in a comment of mine). /* the fun->su exists as soon as -fstack-usage is passed, but it is filled much later, by the RTL pass named "pro_and_epilogue" at gcc-8.3.0/gcc/config/i386/i386.c:13930 in function ix86_expand_prologue; that pass is pass_data_thread_prologue_and_epilogue defined in gcc/function.c line 6553 ... */ To insert that second pass, I tried many things and failed. I was expecting that an rtl- prefix is needed for an RTL pass. My plugin_init contains struct register_pass_info my_framesize_pass_info; my_framesize_pass_info.pass = make_pass_chariot_framesize (g); //#warning the below reference pass name is wrong for my_framesize_pass_info my_framesize_pass_info.reference_pass_name = "rtl-pro_and_epilogue"; my_framesize_pass_info.ref_pass_instance_number = 1; my_framesize_pass_info.pos_op = PASS_POS_INSERT_AFTER; register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &my_framesize_pass_info); But for some reason I cannot understand the reference_pass_name is wrong. Using "rtl-pro_and_epilogue" don't work. And I tried many variants without any success during several hours. So what is the reference_pass_name to use with register_callback like above to mention that pass_data_thread_prologue_and_epilogue defined in gcc/function.c line 6553 ? The entire code (of that proof-of-concept work in progress) is temporarily available on http://starynkevitch.net/Basile/chariotdemo-2019-Apr-10-5414f7e3a173.tar.bz2 which is a small archive of 14340 bytes. Please notice that the code I have written in collaboration with my colleagues Franck Védrine (in BCC) and Yves Lhuillier at CEA LIST is under GPLv3+ license. But that example also contains some third-party tiny code taken from https://wiki.osdev.org/Bare_Bones and in good faith we don't know what license is that code (files kernel.c etc...) but we guess it is morally in the public domain or open source (but we are not lawyers) since given as an example on some wiki page. Regards -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: GCC 8: adding, thru a plugin, an analyzing RTL pass after pro_and_epilogue issue with its reference_pass_name
On 4/10/19 8:44 PM, David Malcolm wrote:
On Wed, 2019-04-10 at 17:53 +0200, Basile Starynkevitch wrote:
I don't want to pollute the mailing list archive. My previous email is
on https://gcc.gnu.org/ml/gcc/2019-04/msg00133.html so please refer to
it. And that previous email mentions
http://starynkevitch.net/Basile/chariotdemo-2019-Apr-10-5414f7e3a173.tar.bz2
which is my self-contained example code.
Thanks for your help. I finally found my bug. It was my fault. I
incorrectly coded:
const pass_data pass_data_chariot_framesize =
{
GIMPLE_PASS, /* type */ /// WRONG should be RTL_PASS
"chariot_framesize", /* name */
OPTGROUP_NONE, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_ssa, /* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
0, /* todo_flags_finish */
};
and then I inserted such a wrong pass (it is not possible to insert a
GIMPLE_PASS after an existing RTL_PASS).
However, the result error message is very cryptic:
cc1: fatal error: pass ‘pro_and_epilogue’ not found but is referenced by
new pass ‘chariot_framesize’
perhaps the error message should mention a type mismatch.
Thanks for your help.
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
[off-topic] freelancing GCC plugin development activity
Hello List, This is off-topic here, but I would be interested in free-lance developing of GCC plugins (working remotely mostly from home, near Paris, France) for clients or corporations in the Euro zone. If some of you is interested by having me as a sub-contractor, please contact me privately by email to bas...@starynkevitch.net Thanks for reading. Cheers PS. My resume is here: http://starynkevitch.net/Basile/cv-Basile-Starynkevitch.pdf -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
[RFC] Adding Python as a possible language and it's usage
Hello All, In https://gcc.gnu.org/ml/gcc/2018-07/msg00233.html Martin Liška wrote: I've recently touched AWK option generate machinery and it's quite unpleasant to make any adjustments. My question is simple: can we starting using a scripting language like Python and replace usage of the AWK scripts? It's probably question for Steering committee, but I would like to see feedback from community. I would suggest also (and perhaps instead) considering using GNU Guile https://www.gnu.org/software/guile/ (personally, I prefer Guile to Python, but that is just my preference) Since Guile is the preferred GNU scripting language (for example Guile is a GNU project, but AFAIK Python is not). BTW, I dislike Python syntax (my personal taste is an allergy to significant spaces, but I admit it is just a matter of taste and I could contribute some Python code in the future if it becomes needed). Also, I am noticing that these days the Python project might have some governance issues (see e.g. https://lwn.net/Articles/759654/ in case you did not heard about it). However, the idea of depending more deeply on a good scripting language in GCC is very pleasant. Regards -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
misleading message when failing to insert a pass...
Hello All
(I've found this issue with the GCC MELT branch rev 169469, but I strongly
believe it is not directly related to MELT and should happen with the trunk
also. You could run the testsuite/melt/topengpu-1.c test, a comment in that
file describes how to run the test)
First, a pass inserted by a plugin (or a MELT module) into the pass tree has
to be of the same type. So a GIMPLE_PASS can only be inserted before or
after another GIMPLE pass, a SIMPLE_IPA_PASS can only be be inserted near a
SIMPLE_IPA_PASS, and an IPA_PASS can only be inserted near an IPA_PASS.
In particular, I find a bit confusing that a SIMPLE_IPA_PASS provided by a
plugin cannot be inserted after an IPA_PASS.
When one try to insert a pass with a kind mismatch, the error message is
very confusing. For instance, I'm getting
cc1 : pass local-pure-const not found but is referenced by new pass
meltopengpu_detect
But the pass 'local-pure-const' does indeed exist. So at least, the error
message should be improved (but I imagine that it is too late to even bother
trying submit a patch to 4.6 trunk now, because we are probably in a stage
[3, 4, don't understand the numbering] which disallows that).
I believe that we should improve the error message. Maybe a message like
"pass found but of incompatible kind with new pass " could be
more understandable.
I also find confusing that the pass 'local-pure-const' is a GIMPLE_PASS in
file ipa-pure-const.c near line 1682 and the file is named ipa*.c (which
suggest an IPA_PASS or SIMPLE_IPA_PASS) but that pass is just a GIMPLE_PASS.
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} ***
Re: Bugzilla spam caused by my merge
On Wed, 2 Feb 2011 14:09:21 -0500
Diego Novillo wrote:
> I would like to apologize for all the bugzilla spam I have caused with
> a recent merge I made. I was committing the merge with 'git svn',
> since I was interested in keeping the commit history. I did not
> realize that this would also commit the svn commit messages with the
> PR numbers, causing the massive bugzilla update.
I am switching to daily use git for the MELT branch. What is the
command to avoid making the same mistake? Any general clues on using
git for GCC work is welcome. I did read
http://gcc.gnu.org/wiki/GitMirror and Dodji dodjiseketeli... gave
me precious advices about it.
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 mine, sont seulement les miennes} ***
hints on debugging memory corruption...
Hello All
(Sorry for such a basic question; very probably there are some GDB tricks
that I ignore).
In my MELT branch I have now some corrputed memory (maybe because I am
inserting a pass at the wrong place in the pass tree). At some point, I call
bb_debug, and it crashes because the field bb_next contains 0x101 (which is
not a valid adress).
So I need to understand who is writing the 0x101 in that field.
How do you folks debug such issues.
An obvious strategy is to use the hardware watchpoint feature of GDB.
However, one cannot nicely put a watchpoint on an address which is not
mmap-ed yet.
But I don't know how to ask gdb to be notified when a given adress is
becoming valid in the address space. Putting a breakpoint on mmap is really
not funny.
Any hints are welcome!
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} ***
switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
Hello All,
I am switching to GIT for my GCC work (mostly the MELT branch, sometimes
submitting patches to trunk). A big thanks to Dodji Seketeli for his very
kind help. If I understand correctly, I am using the GCC git service.
But I have some issues. The GCC MELT branch has very localised changes
(almost all of them are in some files named *melt*). The difference between
MELT and trunk -on files existing in both- is very small usually (usually, a
few lines in toplevel.c). Most of the files are exactly the same.
Now, I am trying for the first time to merge trunk into MELT. In the old SVN
times (last week!), I just did svnmerge merge and most of the time I had no
conflict (because by design MELT is very close to the trunk) at all.
Now, I followed http://gcc.gnu.org/wiki/GitMirror and did
cd /usr/src/Lang/basile-melt-gcc
git merge --squash master
and now I am getting a lot of conflicts that I do not understand. A typical
one is:
Auto-merging gcc/ada/gcc-interface/gigi.h
CONFLICT (add/add): Merge conflict in gcc/ada/gcc-interface/gigi.h
% git status gcc/ada/gcc-interface/gigi.h
# On branch melt-branch
# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both added: gcc/ada/gcc-interface/gigi.h
#
no changes added to commit (use "git add" and/or "git commit -a")
I never in my life touched an y ada related file (neither in trunk, not in
the MELT branch).
And if I ask what is happenning; % git diff gcc/ada/gcc-interface/gigi.h
diff --cc gcc/ada/gcc-interface/gigi.h
index 67a7a47,e45cf13..000
--- a/gcc/ada/gcc-interface/gigi.h
+++ b/gcc/ada/gcc-interface/gigi.h
@@@ -6,7 -6,7 +6,11 @@@
* *
* C Header File *
* *
++<<<<<<< HEAD
+ * Copyright (C) 1992-2010, Free Software Foundation, Inc. *
++===
+ * Copyright (C) 1992-2011, Free Software Foundation, Inc. *
++>>>>>>> master
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@@ -861,10 -861,9 +865,16 @@@ extern tree build_allocator (tree type
Entity_Id gnat_proc, Entity_Id gnat_pool,
Node_Id gnat_node, bool);
++<<<<<<< HEAD
+/* Fill in a VMS descriptor for EXPR and return a constructor for it.
+ GNAT_FORMAL is how we find the descriptor record. GNAT_ACTUAL is how
+ we derive the source location on a C_E */
+extern tree fill_vms_descriptor (tree expr, Entity_Id gnat_formal,
++===
+ /* Fill in a VMS descriptor of GNU_TYPE for GNU_EXPR and return the result.
+GNAT_ACTUAL is the actual parameter for which the descriptor is built. */
+ extern tree fill_vms_descriptor (tree gnu_type, tree gnu_expr,
++>>>>>>> master
Node_Id gnat_actual);
/* Indicate that we need to take the address of T and that it therefore
I was expecting the git merge to copy all the changes from trunk into the
MELT branch. I don't feel the above as a "conflict" (and in the svnmerge
merge times, it was not one). I just want git to bring all the changes from
trunk into GCC MELT. And I expect conflicts -if any- only on the very files
that are common (ie exisiting in both), but different in the MELT branch and
in the trunk (like perhaops gcc/Makefile.in). I dont understand why there is
a conflict on an ada related file I never touched in my life.
What did I do wrong? What is the good way to merge the trunk back into my
MELT branch using git? How can I ask git to ignore such "conflicts" (as
svnmerge merge did)?
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} ***
Re: switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
On Mon, Feb 07, 2011 at 11:59:23AM +0100, Andreas Schwab wrote:
> Basile Starynkevitch writes:
> The easiest way to get things going is to create a dummy merge in the
> melt-branch that records the last svn merge you made. To do that you
> need to find the last merged revision on the master branch and merge it
> using the ours strategy. Then you can merge the master branch as usual.
>
> $ git merge -s ours bd785057b42734e859f64428467a673ee3c00372
> $ git merge master
Thanks a big lot. Apparently, something worked, but I cannot figure out how
you got that bd785057b42734e859f64428467a673ee3c00372 SHA1 key. I thought it
would appear in the git log output.
I'm trying hard to understand how to reliably and painlessly merge trunk
into the MELT branch. I am using the git mirror
git://gcc.gnu.org/git/gcc.git but I don't understand well if I should use
only it, or also git svn dcommit (which I do use).
I also cannot figure out how to reliably get the Svn id of the trunk gotten
by Git. With svnmerge, I had the information at the beginning of
svnmerge-*.txt
Regards, and many thanks.
--
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} ***
Re: hints on debugging memory corruption...
On Thu, 10 Feb 2011 15:32:39 +0100
Dodji Seketeli wrote:
> Joern Rennecke writes:
>
> > Quoting Tom Tromey :
> >
> >>>>>>> "Basile" == Basile Starynkevitch writes:
> >>
> >> Basile> So I need to understand who is writing the 0x101 in that field.
> >
> >
> >> One thing to watch out for is that the memory can be recycled. I've
> >> been very confused whenever I've forgotten this. I have a hack for the
> >> GC (appended -- ancient enough that it probably won't apply) that makes
> >> it easy to notice when an object you are interested in is collected.
> >> IIRC I apply this before the first run, call ggc_watch_object for the
> >> thing I am interested in, and then see in what GC cycle the real one is
> >> allocated.
> >
> > If what you are looking for survives such a change, postponing garbage
> > collection so it won't happen till the crash can make things simpler.
>
> For the sake of archiving these tricks how do you postpone garbage
> collection in practise?
>
BTW, postponing garbage collection is completely inpossible for me (at
the most, I could disable it in the gdb debugger, but not in real MELT
runs), since the GC (I mean the ggc_collect() routine) is called at
arbitrary moments by the MELT runtime (it is called from the MELT
garbage collector, routine melt_garbcoll(), which takes the appropriate
measures -together with the MELT translator- to do that safely.)
Thanks for all the help. I did find out what was wrong: it was my
(incorrect) understanding of get_loop_body. I thought (incorrectly)
that it returned a GTY-ed pointer.
In my opinion, that function has a bizarre property: it returns a
calloc-ed array of basic_block-s, which are themselves GTY-ed (that is
managed by the Ggc collector with the help of GTY annotations for
gengtype).
What I find bizarre, is that get_loop_body returns a manually managed
memory data chunk (an array, actually) of Ggc-ed pointers (as every one
guess, I do like the idea of a garbage collector, and my insane wish is
that GCC would have much more GTY-ed data. I do know that this mine
position is against the majority). I would find much more logical (or
at least more elegant to my eyes) if get_loop_body returned (for
instance) a GTY-ed vector [or any other GTY ((variable)) thing] of
loop-s pointers. Strangely, it doesn't!
In MELT parlance, I cannot simply make a MELT primitive which invokes
get_loop_body. It has to be interfaced by a MELT function which builds
a MELT tuple of MELT boxed basic_block-s. Now, this function needs
support from the MELT runtime to permit mutation of MELT boxed
basic_block-s. So I had to generate the meltgc_basicblock_updatebox in
file gcc/meltrunsup.h [that file is MELT generated. MELT is now able to
generate all the boxing, upboxing, hashmapping... of any GTY-ed
ctypes]. So I had to improve the MELT generator (file
melt/warmelt-outobj.melt) to do that generation of updatebox routines.
Once the generated code was better, I could commit it (using git) to
the MELT branch.
Now, I have to merge the latest trunk into the MELT branch, but since I
switched to git, I am very scared to do that, and I am not sure to
understand the reliable procedure to do so. (I was able to merge once
the trunk into MELT using git, but that was with the kind help of
Andreas Schwab and Dodji Seketeli, and I am not sure to have understood
all..).
Some of my uses of git (on GCC & MELT) gives me bizarre (hence scary)
messages. I am really ashamed to be a git newbie. I am sort of able to
use it on some (own, non GCC) code, but I am very scared of messing GCC
with git and I use it on GCC MELT with fear.
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 mine, sont seulement les miennes} ***
Re: Graduate research - how GCC compiles PTHREAD Mutex routines into x86/Linux Kernel 2.6 assembler
On Mon, 21 Feb 2011 22:26:09 -0500
Edmon Begoli wrote:
> Hi,
>
> My name is Edmon Begoli and I am a graduate student in computer science.
>
> I am writing a graduate research paper on how are concurrent routines complied
> in different languages. I want to start with a sort of a base case showing how
> are Mutexes and thread initiation routines in C compiled by GCC into
> assembler.
>
You question very probably belongs more to gcc-help@
> I tried to look into a assembly and I did search for several days
> forums and forums and manuals
> but I could not find some simple example or a piece of a source code
> that shows how may
> piece of code like this:
>
> http://www.cs.cf.ac.uk/Dave/C/node31.html#SECTION003117100
>
> be compiled into for example some basic version of Intel x86 assembler
> on Linux 2.6 kernel.
your example there is
#include
pthread_mutex_t count_mutex;
long long count;
void increment_count()
{ pthread_mutex_lock(&count_mutex);
count = count + 1;
pthread_mutex_unlock(&count_mutex);
}
As far as I know, there is nothing special in GCC to compile such a code. All
the interesting stuff happens in pthread routines (like pthread_mutex_lock). To
understand in detail what GCC is doing, you could save the above code chunk in
a file lockedcount.c -inside an otherwise emptyy directory- and compile that
file with
gcc -phtread -S -O2 -fdump-tree-all -fverbose-asm lockedcount.c
Then you'll see the generated assembly code lockedcount.s and many "dump" files
which are showing the various internal representations (Gimple, Gimple/SSA,
...) of the code within GCC.
On my computer the function gets compiled to
.p2align 4,,15
.globl increment_count
.type increment_count, @function
increment_count:
.LFB1:
.cfi_startproc
subq$8, %rsp#,
.cfi_def_cfa_offset 16
movl$count_mutex, %edi #,
callpthread_mutex_lock #
addq$1, count(%rip) #, count
movl$count_mutex, %edi #,
addq$8, %rsp#,
.cfi_def_cfa_offset 8
jmp pthread_mutex_unlock#
.cfi_endproc
.LFE1:
As you can see, the synchronisation routines (pthread_mutex_lock...) get called
like any other ordinary routine. All the synchronisation magic happens inside
them (in the libpthread.so library). You'll need to dig the source code of
glibc/NPTL to understand the details.
When your work is done, please publish it (in English) on some publicly
accessible web page. I'm sure that would interest some people.
Regards, good luck.
--
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: Can You Put Comments Into GCC Compiler Options Files?
On Tue, 22 Feb 2011 18:09:40 -0800
Ian Lance Taylor wrote:
>
> No comments are permitted in the contents of options files read using
> the @file syntax. The contents of the file are simply interpreted as
> command line arguments separated by whitespace. Double quotes, single
> quotes, and backslashes may be used in the usual way to add whitespace
> to arguments.
Maybe we should change that. Do people find such a change useful for 4.7?
If yes, with what comment lexical syntax? A leading # on a line?
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 mine, sont seulement les miennes} ***
temporarily giving up using Git for GCC MELT
Hello All,
Even with the help of very nice people and of the gcc@ list, I am unable to
use git for GCC MELT with ease. I tried this entire week without success
My only issue is merging the trunk into GCC MELT but since this is something
I am doing several times a week, it makes me temporarily give up the use of
GIT (which I find otherwise very nice).
GCC MELT has an important property: is is almost entirely a strict superset
of the trunk. To be more precise, the only difference between GCC MELT and
the trunk are
* lots of MELT specific files or directories: their name contain melt or
MELT inside.
* significant differences in building procedures that is in configure.ac
and Makefile.{tpl,def} & Makefile.in files (either toplevel source directory
or gcc/ subdirectory). The MELT branch is conceptually only adding things.
The MELT branch building is buggy (for example, make -j don't work, so you
need to do a serial make) and I am trying progressively to improve it, but
moving code out of files and using include features...
* very small differences in the code proper:
a. Several MELT specific options -mostly named -fmelt-* - to
gcc/common.opt
b. The gcc/toplev.c adds call to melt_initialize() & melt_finalize()
Of course, the similarity of MELT with the trunk is one purpose, since MELT
is designed to be compilable as a plugin. Actually, even in the MELT branch,
the MELT propoer code is a quasi- or pseudo- plugin.
Given the above properties of GCC MELT, with the svnmerge tool from
subersion-tools package (in Debian) the merge of trunk into MELT is just
running
svnmerge merge
and then rebuilding to check that everything is ok. Most of the time (that
is, when the trunk did not touch gcc/toplev.c or gcc/common.opt or build
files like Makefile.in...) I'm getting not conflict with that. With git I
always got hundreds of conflict... So I am temporarily giving up using GIT.
Aopparently, git is a very powerful tool, and there is some GCC specific way
to use it which I did not understood. I have no issues using git on small
projects. There are many things I don't understand in git.
By the way, if you happen to be in Paris' region (in France) and have a few
yours to help me face to face mastering GIT for GCC MELT, I would be
grateful. I really need to meet people in person & talk to them face to face
(and I don't have IRC) with my laptop.
Regards.
PS. By the way, git clone-ing the GCC git repository takes a lot of time
from Europe. Perhaps having a daily tar ball of the result of that command
available by ftp would be very nice
--
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} ***
Perhaps a mailing list for plugins (& other GCC extensions) is needed?
Hello All,
I have a few subscribers to a french speaking GCC MELT mailing list on
gcc-melt-fre...@googlegroups.com
Since I have several potential non-french speaking but english-speaking users,
I am considering to switch to an english list.
However, my intuition is that a list for plugins developers (including GCC MELT
extensions developers) could be more generally useful.
Those developers have a different point of view than those at g...@gcc.gnu.*.
On gcc@ list, we discuss how to change and improve GCC internals.
On a plugin list, we would discuss how to develop GCC plugins (& MELT
extensions). The point of view is becoming slightly different: plugin
developpers take the GCC plugin API as granted (whatever definition of the GCC
API you take, provided it is usable from inside a plugin to an unmodified GCC).
Of course, I could very easily setup a list like gcc-m...@googlegroups.com to
discuss GCC MELT in english, but I would believe that a more general "plugin"
focussed list, hosted inside gcc.gnu.org, would be very useful.
What do people think? Should plugin developers post their GCC plugins questions
on the existing g...@gcc.gnu.* list, or should we (ideally) make a new
gcc-plug...@gcc.gnu.org list?
A typical GCC plugin question would be perhaps: where should my plugin insert
its pass (with detailed and specific explanations of the plugin goals)?
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 mine, sont seulement les miennes} ***
debug & trace printing from GCC plugins (& MELT extensions)
Hello All,
I have a "philosophical" question about debug & trace printing from
inside GCC plugins (beyond the nearly useless answer that plugins being
outside of GCC could do what they wish), in particular from MELT (&
MELT extensions).
For various reasons (in particular because debugging MELT code with gdb
is possible, but not very fun) I like to have debug printing. For
instance, I added the DBGPRINTF macro inside gengtype.
Likewise, both the melt runtime (ie the melt.so metaplugin itself) and
MELT code extensively uses such debug & trace printing.
Of course, it can be (and usually it is) disabled, both at configure &
compile time and at run time. So the average user don't see it at all.
However, plugin developers find it quite useful, and MELT extensions
could not be easily developped without (and probably, any other big GCC
plugin).
So please accept (at least temporily) the usefulness of debug & trace
printing.
My question then is how to implement it nicely?
To have it disabled at configure time, the trick is very easy:
I wrap such debug printing with #if ENABLE_CHECKING
To have it disabled at runtime, I also have an easy trick. An option,
eg -fplugin-melt-arg-debug.
My question is then, where should the debug printing go?
I usually print to dump_file -and wrap the call with something similar
to
#if ENABLE_CHECKING
#define dbgprintf_raw(Fmt,...) do{if (want_debug && dump_file) \
{fprintf(dump_file, Fmt, ##__VA_ARGS__); fflush(dump_file);}}while
(0)
#define dbgprintf(Fmt,...) dbgprintf_raw("@%s:%d: " Fmt "\n", \
basename(__FILE__), __LINE__, ##__VA_ARGS__)
#else
#define dbgprintf(Fmt,...) (void)0
#endif
However, debug printing to dump_file is not always appropriate:
Some code, in particular code called from plugin initialization, is
called outside of any pass. In that case, dump_file is null (and I even
added shameful tricks to temporarily set it stderr & restore it to NULL)
And I don't know if debug printing should go to stdout or to stderr.
Your insights are welcome. How do you add debug printing inside your plugins?
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 mine, sont seulement les miennes} ***
gengtype state & srcdir???
Hello All,
The gengtype state is persisted into a textual file with a lispy (actually
MELT-y) appearence.
This is very important for plugins (notably those using GTY).
The gengtype state is generated by gcc/Makefile.in rule:
s-gtype: build/gengtype$(build_exeext) $(filter-out [%], $(GTFILES)) \
gtyp-input.list
# First, parse all files and save a state file.
$(RUN_GEN) build/gengtype$(build_exeext) $(GENGTYPE_FLAGS) \
-S $(srcdir) -I gtyp-input.list -w gtype.state
Notice that the $(srcdir) above is actually the gcc/ subdirectory of GCC source
tree.
With Jeremie Salvucci, I tried to make the state file not too sensitive of the
source tree path. The intent is that if the source directory changes -and
everything else stays the same- the state file should not change a lot (so that
a diff would find only a few lines of changes, not many thousands). The reason
is that gengtype.state should be installed somewhere.
The gengtype state file contains source location information related to GTY. So
it does contain (conceptually) lots of references to the source tree.
To have the gengtype state file not too sensitive to the source tree location
in the filesystem, we added tricks into gengtype-state.c (e.g. functions
write_state_fileloc & write_state_files_list).
However, some source files considered by gengtype are outside of $(srcdir)
because they are somewhere else in the GCC source tree.
To be specific, examine the gtype.state file (with an editor like emacs).
You'll find things like
(!srcfile 511 "defaults.h")
(!file 511 "/usr/src/Lang/basile-melt-gcc/include/hashtab.h")
(!file 511 "/usr/src/Lang/basile-melt-gcc/include/splay-tree.h")
(!srcfile 511 "bitmap.h")
(!srcfile 511 "alias.h")
(!srcfile 511 "coverage.c")
(!srcfile 511 "rtl.h")
(!srcfile 511 "optabs.h")
(!srcfile 511 "tree.h")
(!srcfile 511 "libfuncs.h")
(!file 511 "/usr/src/Lang/basile-melt-gcc/libcpp/include/symtab.h")
(!file 511 "/usr/src/Lang/basile-melt-gcc/include/obstack.h")
(!srcfile 511 "real.h")
(!srcfile 511 "function.h")
(!srcfile 511 "insn-addr.h")
(!srcfile 511 "hwint.h")
(!srcfile 511 "fixed-value.h")
(!srcfile 511 "output.h")
(!srcfile 511 "cfgloop.h")
(!srcfile 511 "cselib.h")
(!srcfile 511 "basic-block.h")
(!srcfile 511 "ipa-ref.h")
(!srcfile 511 "cgraph.h")
(!srcfile 511 "reload.h")
(!srcfile 511 "caller-save.c")
(!srcfile 511 "alias.c")
(!srcfile 511 "bitmap.c")
(!srcfile 511 "cselib.c")
(!srcfile 511 "cgraph.c")
(!srcfile 511 "ipa-prop.c")
(!srcfile 511 "ipa-cp.c")
(!srcfile 511 "ipa-inline.c")
(!srcfile 511 "matrix-reorg.c")
(!srcfile 511 "dbxout.c")
(!srcfile 511 "ipa-struct-reorg.c")
(!srcfile 511 "dwarf2out.c")
(!srcfile 511 "dwarf2asm.c")
(!srcfile 511 "tree-vect-generic.c")
(!srcfile 511 "dojump.c")
(!srcfile 511 "emit-rtl.c")
(!srcfile 511 "except.h")
(!srcfile 511 "explow.c")
(!srcfile 511 "expr.c")
(!srcfile 511 "expr.h")
(!srcfile 511 "function.c")
(!srcfile 511 "except.c")
(!srcfile 511 "gcse.c")
(!srcfile 511 "godump.c")
(!srcfile 511 "integrate.c")
(!srcfile 511 "lists.c")
(!srcfile 511 "optabs.c")
(!srcfile 511 "profile.c")
So most of the source files considered by gengtype are indeed in the $(srcdir)
of the gcc/Makefile.in that is in the gcc/ subdirectory of GCC source tree. But
some are outside, e.g. in include/ or libcpp/
I feel we could improve that by passing the GCC source tree as the -S argument
to GCC, etc.
Do you think it is worth working on that now? Could such a minor patch be
accepted for 4.6 (I believe that no, but I am not sure).
If yes, what is the canonical way to get the GCC source tree topdirectory (the
one containing gcc/ & include/ & libcpp/ etc.) from a gcc/Makefile.in rule?
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 mine, sont seulement les miennes} ***
Re: debug & trace printing from GCC plugins (& MELT extensions)
On Tue, 08 Mar 2011 21:07:39 +
Dave Korn wrote:
> On 07/03/2011 15:39, Basile Starynkevitch wrote:
>
> > So please accept (at least temporily) the usefulness of debug & trace
> > printing.
> >
> > My question then is how to implement it nicely?
>
> > And I don't know if debug printing should go to stdout or to stderr.
>
> MELT is for writing new passes, right? So it could use the existing
> per-pass dump files mechanism I would expect.
Yes, but some processing happens outside passes (like complex
initializations at least). And I believe this is also true for some
other plugins. The question becoms where and how should the debug
printing happens in that case.
I'm sure the question is not MELT specific. Imagine a plugin (coded in
C) which uses some database, or some web services, or provide a web or
a graphical interface. Then its initialization code also need debug
printing.
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 mine, sont seulement les miennes} ***
Using GCC bugzilla for MELT specific bugs?
Hello,
I have a few users reporting bugs (so far on
gcc-melt-fre...@googlegroups.com in French) for the MELT plugin and branch.
Can these users use GCC bugzilla? If yes, how can they mark the bug as MELT
specific?
The typical MELT bug is very often (& sadly) related to the MELT language
itself. As a (shameful) example, Pierre Vittet just reported in
http://groups.google.com/group/gcc-melt-french/browse_thread/thread/7ab6c2ca53b2b4dc
that MELT failed to translate correctly a simple MELT code like
(let ((salut '0))
(setq salut '1)
)
Any Scheme or Lisp practitionner would expect that to work, and it should
work in MELT [but MELT has bugs]. That was a bug I easily corrected and
committed svn rev 170818.
Is GCC bugzilla the right place to report such bug totally specific to MELT?
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} ***
is trunk in stage 4 (4.6) or in stage 1 (4.7) - file gcc/BASE-VER?
Hello All
I thought http://gcc.gnu.org/ml/gcc/2011-03/msg00081.html
that trunk was still in stage 4, that is 4.6 very close to be released.
However, it seems that the gcc/BASE-VER file of gcc trunk rev 170941 says
4.7.0 and according to svn log it changed:
r170936 | jakub | 2011-03-14 14:07:26 +0100 (Mon, 14 Mar 2011) | 2 lines
* BASE-VER: Change to 4.7.0.
So what is the current status of GCC trunk? Has 4.6 being released?
Neither http://gcc.gnu.org/ nor ftp://ftp.gnu.org/gnu/gcc/ seems to mention
a 4.6.0 release.
Or perhaps the BASE-VER is changed ahead of time?
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} ***
Re: [MELT] issue with the garbage collector
On Wed, 16 Mar 2011 10:56:32 +0100
wrote:
> I guess I have found a bug about related to the garbage collector in
> MELT:
> I am using the version 170521.
I added Pierre's failed case to
gcc/testsuite/melt/tgissue-pv-{1m.melt,1c.c,1run.sh} and I added some
tweeks in MELT gcc/melt-runtime.c which apparently correct the issue.
Honestly, I am not entirely sure to understand what the bug was (it is
related to garbage collection of finalized MELT special values, such as
boxed FILE-s or boxed PPL data) and if I corrected it, but at least
Pierre's test seems to pass.
The better GCC MELT branch is svn revision 171181.
I discussed (with Pierre) the issues on gcc-melt-french@googlegroups. I
tried to summarize each french message in a short english abstract. See
the thread on
http://groups.google.com/group/gcc-melt-french/browse_thread/thread/47088e96002e98af
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 mine, sont seulement les miennes} ***
Serializing mixed gimple data from a plugin in LTO?
Hello All,
Let's imagine someone is writing a plugin (or a MELT extension...) which
computes some complex information around gimple in a pass before LTO
serialization and re-uses that information in a later pass after LTO
serialization. A possible way to associate data inside a plugin to some gimples
would be to have hash tables (keys being Gimple, associated value being some
complex information specific to the plugin). The the plugin would compute &
serialize [i.e. write or output] data in a pass before LTO and deserialize
[re-read or input] that data at LTO time.
The writing happens in the write_summary and write_optimization_summary hooks
of struct ipa_opt_pass_d of file tree-pass.h. The reading happens in
read_summary & read_optimization_summary hooks.
But what I cannot understand is how can such a plugin know what are the gimple
involved. Since the plugin needs to persist (i.e. serialize into LTO stream &
de-serialize) an hash table mapping some gimples to its data, the plugin need
to know what gimples are serialized & deserialized, to restore at LTO streaming
read the common gimple pointers (the same gimple pointer should appear in the
function & the hash table)
I would imagine gcc/lto-streamer-out.c would have a plugin hook inside
output_gimple_stmt but this is not the case...
I admit I don't have a clear picture of LTO streams usage (& customization)
from plugins.
Or perhaps it is not possible yet???
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 mine, sont seulement les miennes} ***
realmpfr.h not in PLUGIN_HEADERS?
Helo All,
It seems that, since realmpfr.h is not listed in the PLUGIN_HEADERS in
gcc/Makefile.in, it cannot be used from plugins.
Is there a reason for that, or what? I feel that plugins need to know about
and about the real_from_mpfr & mpfr_from_real functions.
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} ***
