* MELT tutorial on the wiki @ 2009-07-29 15:52 Basile STARYNKEVITCH 2009-07-30 21:17 ` Tom Tromey 0 siblings, 1 reply; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-07-29 15:52 UTC (permalink / raw) To: GCC Mailing List Hello All, I added as a turorial on the wiki, a small MELT pass which warns against fprintf(stdout, ...) in the compiled code. For GCC hackers, is the page http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT clear enough? (of course, the pass implementation is imperfect, but I have hard time finding good *small* examples). regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-29 15:52 MELT tutorial on the wiki Basile STARYNKEVITCH @ 2009-07-30 21:17 ` Tom Tromey 2009-07-31 6:27 ` Basile STARYNKEVITCH 2009-08-01 8:44 ` Paolo Bonzini 0 siblings, 2 replies; 20+ messages in thread From: Tom Tromey @ 2009-07-30 21:17 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: GCC Mailing List >>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes: Hi Basile. Basile> I added as a turorial on the wiki, a small MELT pass which warns Basile> against fprintf(stdout, ...) in the compiled code. Basile> For GCC hackers, is the page Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT Basile> clear enough? I've been looking for a very simple way to do some kinds of static analysis on gdb, so today I tried building the MELT branch in hopes it would serve this need. Unfortunately, it didn't compile. With C++ enabled, I got this failure: /space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal error: chrono: No such file or directory With just C enabled, I got: make[2]: *** No rule to make target `install-melt-headers', needed by `install'. Stop. make[2]: Leaving directory `/space/tromey/MELT/build/gcc' In both cases I just configured with --disable-bootstrap --enable-melt, plus the appropriate --enable-langauges option. This is on x86 F11. Basile> (of course, the pass implementation is imperfect, but I have hard time Basile> finding good *small* examples). My gdb examples involve finding broken code that can't be diagnosed by the compiler. Most of my examples are simple, but also actually useful. For example, gdb has function that in the past could return null, but which now cannot. So, I'd like to find all places where the return result is checked. Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops. It is not ok to 'return' or 'goto' from inside the inner loop, as this causes hard-to-find bugs. So, it would be nice to find any place that tries this. Or, there is a data type in gdb that used to be freed using 'xfree', but which now requires a special function to be called instead. So, it would be nice to find any place where xfree is passed an argument of this type. Etc. For my purposes, any kind of simple analysis pass that is simple to hack and doesn't require me to learn too much would be ideal. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-30 21:17 ` Tom Tromey @ 2009-07-31 6:27 ` Basile STARYNKEVITCH 2009-07-31 17:52 ` Tom Tromey 2009-08-01 8:44 ` Paolo Bonzini 1 sibling, 1 reply; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-07-31 6:27 UTC (permalink / raw) To: tromey; +Cc: GCC Mailing List Tom Tromey wrote: >>>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes: > > Hi Basile. > > Basile> I added as a turorial on the wiki, a small MELT pass which warns > Basile> against fprintf(stdout, ...) in the compiled code. > > Basile> For GCC hackers, is the page > Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT > Basile> clear enough? > A very big thanks to Tom for looking at the page & trying MELT. I would be very proud if Tom happens to use it. > I've been looking for a very simple way to do some kinds of static > analysis on gdb, so today I tried building the MELT branch in hopes it > would serve this need. Unfortunately, it didn't compile. > My current belief is that MELT is easier built (and used) as a GCC-trunk (or future GCC-4.5) plugin melt.so. The advantage for you is also to be better fit to your GCC (provided it is similar enough to a recent trunk and have plugins enabled). See the http://gcc.gnu.org/wiki/MELT%20tutorial There are however a few caveats when building MELT as a plugin: a) The patch (submitted to the trunk on gcc-patches@) http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html which provides a gengtype usable for MELT as a plugin is required. I hope it will be reviewed & accepted for the trunk. The current gengtype (in recent trunk) is not good enough for complex plugins like MELT. Of course, you have the patched gengtype.c in the MELT branch. Currently, this is the most annoying issue when building MELT as a plugin. b) some more headers are needed to MELT. the PLUGIN_HEADERS in gcc/Makefile.in is really incomplete. See footnote 9 of http://gcc.gnu.org/wiki/MELT%20tutorial c) you need to hack the MELT compile script (used to compile MELT generated C code into a shared library), that is, you should edit the file gcc/melt-cc-script.proto of MELT branch to suit your needs, and rename it appropriately. d) you need the PPL library (version 0.10.2 at least; the 0.10 is not enough). This is also needed when graphite is enabled. > With C++ enabled, I got this failure: > > /space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal error: chrono: No such file or directory > > My fault: I had a mysterious message from svnmerge a few days ago about this file. I just copied it manually (from trunk to MELT branch rev 150308 which I just commited). > With just C enabled, I got: > > make[2]: *** No rule to make target `install-melt-headers', needed by `install'. Stop. > make[2]: Leaving directory `/space/tromey/MELT/build/gcc' > > > In both cases I just configured with --disable-bootstrap --enable-melt, > plus the appropriate --enable-langauges option. This is on x86 F11. > You probably missed some configure arguments. The MELT's gcc/configure.ac ends with ## Basile adds a notice if the MELT branch is configured without ## --enable-melt if test "$enabled_melt" != "yes" ; then AC_MSG_NOTICE( [GCC MELT branch is configured WITHOUT enabling melt. Are you sure to want that?]) fi So if you got the GCC MELT branch is configured WITHOUT enabling melt message, your configure is wrong. > Basile> (of course, the pass implementation is imperfect, but I have hard time > Basile> finding good *small* examples). > > My gdb examples involve finding broken code that can't be diagnosed by > the compiler. Most of my examples are simple, but also actually useful. > > For example, gdb has function that in the past could return null, but > which now cannot. So, I'd like to find all places where the return > result is checked. > > Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops. > It is not ok to 'return' or 'goto' from inside the inner loop, as this > causes hard-to-find bugs. So, it would be nice to find any place that > tries this. > > Or, there is a data type in gdb that used to be freed using 'xfree', but > which now requires a special function to be called instead. So, it > would be nice to find any place where xfree is passed an argument of > this type. > > Etc. For my purposes, any kind of simple analysis pass that is simple > to hack and doesn't require me to learn too much would be ideal. > > Tom So Tom, be kind enough to try MELT again (preferably in plugin mode). I am on holidays without email access from august 3rd to august 26th. Tom, you are definitely the best MELT user I could have, since you know much better than I do the internals of GCC! I hope to be able to help you. You could need to extend MELT (mostly file gcc/melt/ana-base.melt) to add all the hooks to GCC that you need and that are not there yet. Ask me for help please! A very big thanks for your message & efforts. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-31 6:27 ` Basile STARYNKEVITCH @ 2009-07-31 17:52 ` Tom Tromey 2009-07-31 20:16 ` Tom Tromey 2009-08-01 6:28 ` Dave Korn 0 siblings, 2 replies; 20+ messages in thread From: Tom Tromey @ 2009-07-31 17:52 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: GCC Mailing List >>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes: Basile> My current belief is that MELT is easier built (and used) as a Basile> GCC-trunk (or future GCC-4.5) plugin melt.so. Yeah, I looked at this, but I really wanted something where I did not have to do much work... no applying patches or hacking scripts. I have very little time for this side project, so most barriers look too big at this point. Tom> In both cases I just configured with --disable-bootstrap --enable-melt, Tom> plus the appropriate --enable-langauges option. This is on x86 F11. Basile> You probably missed some configure arguments. The MELT's Basile> gcc/configure.ac ends with Basile> ## Basile adds a notice if the MELT branch is configured without Basile> ## --enable-melt Basile> if test "$enabled_melt" != "yes" ; then Basile> AC_MSG_NOTICE( Basile> [GCC MELT branch is configured WITHOUT enabling melt. Basile> Are you sure to want that?]) Basile> fi I looked into this a little. It looks like the PPL checks don't work properly in the case where PPL is a system library. I guess I need --with-ppl=/usr ... I will try that later. BTW: IMO, on a branch like this, it would be friendlier for users to: * Check in the correct version of configure * Enable MELT by default, don't require an option * Die in configure if a prerequisite is missing * Have the PPL checks detect the situation where PPL is a system library Otherwise whatever error messages there might be are just lost in the noise. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-31 17:52 ` Tom Tromey @ 2009-07-31 20:16 ` Tom Tromey 2009-08-01 6:11 ` Basile STARYNKEVITCH 2009-08-01 6:28 ` Dave Korn 1 sibling, 1 reply; 20+ messages in thread From: Tom Tromey @ 2009-07-31 20:16 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: GCC Mailing List Tom> I looked into this a little. It looks like the PPL checks don't work Tom> properly in the case where PPL is a system library. I guess I need Tom> --with-ppl=/usr ... I will try that later. This worked but now I get an error because melt_generated_dir is not defined in gcc/Makefile. I don't know what value it ought to have. /usr/bin/install: cannot create regular file `/warmelt-first-3.c': Permission denied Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-31 20:16 ` Tom Tromey @ 2009-08-01 6:11 ` Basile STARYNKEVITCH 2009-08-01 7:06 ` Ralf Wildenhues ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-08-01 6:11 UTC (permalink / raw) To: tromey; +Cc: GCC Mailing List Tom Tromey wrote: > Tom> I looked into this a little. It looks like the PPL checks don't work > Tom> properly in the case where PPL is a system library. I guess I need > Tom> --with-ppl=/usr ... I will try that later. I don"t know really how to fix that quickly! I must confess that autoconf related files in GCC scares me a big lot. BTW, I really cannot imagine why GCC still required autoconf 2.59 specifically, and not 2.63. What is so specific about 2.59? > > This worked but now I get an error because melt_generated_dir is not > defined in gcc/Makefile. I don't know what value it ought to have. Thanks for the bug report. In fact, melt_generated_dir should be the same as melt_source_dir I just committed rev 150330 of MELT branch to fix that. Tom, could you be patient & kind enough to try again! Many thanks! > > /usr/bin/install: cannot create regular file `/warmelt-first-3.c': Permission denied > > > Tom My public apologies for the bug! Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:11 ` Basile STARYNKEVITCH @ 2009-08-01 7:06 ` Ralf Wildenhues 2009-08-02 14:57 ` Paolo Bonzini 2009-08-03 16:23 ` Tom Tromey 2 siblings, 0 replies; 20+ messages in thread From: Ralf Wildenhues @ 2009-08-01 7:06 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: tromey, GCC Mailing List * Basile STARYNKEVITCH wrote on Sat, Aug 01, 2009 at 08:10:24AM CEST: > I don"t know really how to fix that quickly! I must confess that > autoconf related files in GCC scares me a big lot. BTW, I really > cannot imagine why GCC still required autoconf 2.59 specifically, > and not 2.63. What is so specific about 2.59? I will post patches to move to 2.64 and Automake 1.11; they are ready (I only need to finish writing the emails) but I'm off-list for the next week starting now. :-) Cheers, Ralf ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:11 ` Basile STARYNKEVITCH 2009-08-01 7:06 ` Ralf Wildenhues @ 2009-08-02 14:57 ` Paolo Bonzini 2009-08-03 16:23 ` Tom Tromey 2 siblings, 0 replies; 20+ messages in thread From: Paolo Bonzini @ 2009-08-02 14:57 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: tromey, GCC Mailing List >> Tom> I looked into this a little. It looks like the PPL checks don't work >> Tom> properly in the case where PPL is a system library. I guess I need >> Tom> --with-ppl=/usr ... I will try that later. > > I don"t know really how to fix that quickly! I must confess that > autoconf related files in GCC scares me a big lot. Yes they are complicated but (unlike some other projects) people have a handle on them... > BTW, I really cannot > imagine why GCC still required autoconf 2.59 specifically, and not 2.63. > What is so specific about 2.59? Nothing, but just like Autoconf 2.50 should have been 3.0, similarly 2.60 should have been a major version number as it changed datadir from /usr/share to /usr/share/package, among other things. In fact, GCC moved smoothly from to first 2.5x it used to 2.59, but stopped there. I shouldn't say so because I was one of the main contributors (with Ralf and with Eric Blake), but I'm sure that people on the list will appreciate Autoconf 2.64. Which should have been another 3.0, even though the user-visible changes are not too many. Paolo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:11 ` Basile STARYNKEVITCH 2009-08-01 7:06 ` Ralf Wildenhues 2009-08-02 14:57 ` Paolo Bonzini @ 2009-08-03 16:23 ` Tom Tromey 2009-08-03 19:21 ` Basile STARYNKEVITCH 2 siblings, 1 reply; 20+ messages in thread From: Tom Tromey @ 2009-08-03 16:23 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: GCC Mailing List Basile> Thanks for the bug report. In fact, melt_generated_dir should be the Basile> same as melt_source_dir Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you Basile> be patient & kind enough to try again! Many thanks! Thanks, that worked. Now to actually try MELT... exciting. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-03 16:23 ` Tom Tromey @ 2009-08-03 19:21 ` Basile STARYNKEVITCH 0 siblings, 0 replies; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-08-03 19:21 UTC (permalink / raw) To: Tom Tromey; +Cc: GCC Mailing List Tom Tromey wrote: > Basile> Thanks for the bug report. In fact, melt_generated_dir should be the > Basile> same as melt_source_dir > > Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you > Basile> be patient & kind enough to try again! Many thanks! > > Thanks, that worked. > Now to actually try MELT... exciting. > There are still missing stuff in MELT. In particular, not every GIMPLE feature is currently interfaced, because my way of coding is to progressively add stuff inside MELT to deal with a particular question (or even a test case). Tom, and anyone other brave & kind enough to try MELT, knowing well GCC internals, feel free to add more code inside MELT. Anyone with write access to GCC subversion, good knowledge & good will can add more code inside MELT (I explicitly invite brave people to enhance MELT). This means essentially copy-pasting code (notably inside file gcc/melt/ana-base.melt). But please add a few comments in the code (if you patch it) and also in Changelog.MELT. I'm leaving on holidays within two days. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-31 17:52 ` Tom Tromey 2009-07-31 20:16 ` Tom Tromey @ 2009-08-01 6:28 ` Dave Korn 2009-08-01 6:43 ` Basile STARYNKEVITCH 2009-08-23 20:14 ` Ralf Wildenhues 1 sibling, 2 replies; 20+ messages in thread From: Dave Korn @ 2009-08-01 6:28 UTC (permalink / raw) To: tromey; +Cc: Basile STARYNKEVITCH, GCC Mailing List Tom Tromey wrote: > I looked into this a little. It looks like the PPL checks don't work > properly in the case where PPL is a system library. I guess I need > --with-ppl=/usr ... I will try that later. Were you using a --prefix? The PPL checks (by design I think) only look for PPL in your prefix. cheers, DaveK ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:28 ` Dave Korn @ 2009-08-01 6:43 ` Basile STARYNKEVITCH 2009-08-01 6:58 ` Dave Korn 2009-08-23 20:14 ` Ralf Wildenhues 1 sibling, 1 reply; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-08-01 6:43 UTC (permalink / raw) To: Dave Korn; +Cc: tromey, GCC Mailing List Dave Korn wrote: > Tom Tromey wrote: > >> I looked into this a little. It looks like the PPL checks don't work >> properly in the case where PPL is a system library. I guess I need >> --with-ppl=/usr ... I will try that later. > > Were you using a --prefix? The PPL checks (by design I think) only look for > PPL in your prefix. Sorry DaveK, are you talking of only the MELT branch or of the current gcc trunk (future 4.5)? In the latter (trunk) case, what is the rationale for checking only in the prefix? I have to clean up a bit my MELT's gcc/configure.ac, but I cannot understand why apparently the trunk's gcc/configure.ac does not set any HAVE_ppl flag. Why is there no if test "x${PPPLLIBS}" != "x" ; then AC_DEFINE(HAVE_ppl, 1, [Define if PPL is in use.]) fi near line 4110 of the trunk's gcc/configure.ac ? IMHO, such a test and such a generated #define makes a lot of sense (at least inside plugins). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:43 ` Basile STARYNKEVITCH @ 2009-08-01 6:58 ` Dave Korn 2009-08-03 16:12 ` Tom Tromey 0 siblings, 1 reply; 20+ messages in thread From: Dave Korn @ 2009-08-01 6:58 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: Dave Korn, tromey, GCC Mailing List Basile STARYNKEVITCH wrote: > Dave Korn wrote: >> Tom Tromey wrote: >> >>> I looked into this a little. It looks like the PPL checks don't work >>> properly in the case where PPL is a system library. I guess I need >>> --with-ppl=/usr ... I will try that later. >> >> Were you using a --prefix? The PPL checks (by design I think) only >> look for PPL in your prefix. > > Sorry DaveK, are you talking of only the MELT branch or of the current > gcc trunk (future 4.5)? Trunk. > In the latter (trunk) case, what is the > rationale for checking only in the prefix? I do not know it; I have merely observed the behaviour. It may even not be by design for all I know, though I suspect it makes sense - where else would you look but in the prefix? Prefixes exist to create separation between packages. > I have to clean up a bit my MELT's gcc/configure.ac, but I cannot > understand why apparently the trunk's gcc/configure.ac does not set any > HAVE_ppl flag. > > Why is there no > if test "x${PPPLLIBS}" != "x" ; then > AC_DEFINE(HAVE_ppl, 1, [Define if PPL is in use.]) > fi > near line 4110 of the trunk's gcc/configure.ac ? I imagine nobody has needed one yet. > IMHO, such a test and such a generated #define makes a lot of sense (at > least inside plugins). It certainly does. I'm sure there's no reason not to add it. cheers, DaveK ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:58 ` Dave Korn @ 2009-08-03 16:12 ` Tom Tromey 2009-08-04 13:22 ` Dave Korn 0 siblings, 1 reply; 20+ messages in thread From: Tom Tromey @ 2009-08-03 16:12 UTC (permalink / raw) To: Dave Korn; +Cc: Basile STARYNKEVITCH, GCC Mailing List >>>>> "Dave" == Dave Korn <dave.korn.cygwin@googlemail.com> writes: Dave> Were you using a --prefix? The PPL checks (by design I think) only Dave> look for PPL in your prefix. Dave> I do not know it; I have merely observed the behaviour. It may Dave> even not be by design for all I know, though I suspect it makes Dave> sense - where else would you look but in the prefix? Prefixes Dave> exist to create separation between packages. That didn't seem to be what the code on Basile's branch does. But, if this is what the PPL checks do actually do somewhere, then they are broken. Prefix is for specifying the install tree -- specifying how the build is done is handled by other options. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-03 16:12 ` Tom Tromey @ 2009-08-04 13:22 ` Dave Korn 0 siblings, 0 replies; 20+ messages in thread From: Dave Korn @ 2009-08-04 13:22 UTC (permalink / raw) To: Tom Tromey; +Cc: Dave Korn, Basile STARYNKEVITCH, GCC Mailing List Tom Tromey wrote: >>>>>> "Dave" == Dave Korn <dave.korn.cygwin@googlemail.com> writes: > > Dave> Were you using a --prefix? The PPL checks (by design I think) only > Dave> look for PPL in your prefix. > > Dave> I do not know it; I have merely observed the behaviour. It may > Dave> even not be by design for all I know, though I suspect it makes > Dave> sense - where else would you look but in the prefix? Prefixes > Dave> exist to create separation between packages. > > That didn't seem to be what the code on Basile's branch does. > > But, if this is what the PPL checks do actually do somewhere, then they > are broken. Prefix is for specifying the install tree -- specifying how > the build is done is handled by other options. Ah, I think I misunderstood what's going on. If you specify --with-ppl, what happens: > AC_ARG_WITH(ppl, [ --with-ppl=PATH Specify prefix directory for the installed PPL package > Equivalent to --with-ppl-include=PATH/include > plus --with-ppl-lib=PATH/lib],, with_ppl=no) > AC_ARG_WITH(ppl_include, [ --with-ppl-include=PATH Specify directory for installed PPL include files]) > AC_ARG_WITH(ppl_lib, [ --with-ppl-lib=PATH Specify the directory for the installed PPL library]) > > case $with_ppl in > no) > ppllibs= > ;; > *) > ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx" > pplinc="-I$with_ppl/include $pplinc" > LIBS="$ppllibs $LIBS" > ;; > esac ... is that it looks in /lib and /include, which is fairly likely to succeed - but only because you'll also have $prefix/lib and $prefix/include in the -L and -I settings anyway (when compiling stages 2/3 and target libs). Change your --prefix setting to some other tree where you don't have a PPL installation and all of a sudden using plain "--with-ppl" will fail, and you may think it's because it is looking for ppl in $prefix, when in fact the answer is that it should complain about an empty --with-ppl with no argument. cheers, DaveK ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 6:28 ` Dave Korn 2009-08-01 6:43 ` Basile STARYNKEVITCH @ 2009-08-23 20:14 ` Ralf Wildenhues 1 sibling, 0 replies; 20+ messages in thread From: Ralf Wildenhues @ 2009-08-23 20:14 UTC (permalink / raw) To: Dave Korn; +Cc: tromey, Basile STARYNKEVITCH, GCC Mailing List Hello, * Dave Korn wrote on Sat, Aug 01, 2009 at 08:41:10AM CEST: > Tom Tromey wrote: > > > I looked into this a little. It looks like the PPL checks don't work > > properly in the case where PPL is a system library. I guess I need > > --with-ppl=/usr ... I will try that later. > > Were you using a --prefix? The PPL checks (by design I think) only look for > PPL in your prefix. Just by the way, while it superficially sounds intuitive, I find this a slightly problematic "feature". For example when you're cross-compiling, intending to do a DESTDIR install, and what you pass as --prefix is inhabited by $build system files and libraries and so on. My two cents. Cheers, Ralf ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-07-30 21:17 ` Tom Tromey 2009-07-31 6:27 ` Basile STARYNKEVITCH @ 2009-08-01 8:44 ` Paolo Bonzini 2009-08-01 8:57 ` Basile STARYNKEVITCH 2009-08-03 16:16 ` Tom Tromey 1 sibling, 2 replies; 20+ messages in thread From: Paolo Bonzini @ 2009-08-01 8:44 UTC (permalink / raw) To: tromey; +Cc: Basile STARYNKEVITCH, GCC Mailing List > For example, gdb has function that in the past could return null, but > which now cannot. So, I'd like to find all places where the return > result is checked. > > Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops. > It is not ok to 'return' or 'goto' from inside the inner loop, as this > causes hard-to-find bugs. So, it would be nice to find any place that > tries this. > > Or, there is a data type in gdb that used to be freed using 'xfree', but > which now requires a special function to be called instead. So, it > would be nice to find any place where xfree is passed an argument of > this type. MELT looks extremely cool! You may want to use this too, however: http://lwn.net/Articles/315686/ Paolo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 8:44 ` Paolo Bonzini @ 2009-08-01 8:57 ` Basile STARYNKEVITCH 2009-08-03 16:16 ` Tom Tromey 1 sibling, 0 replies; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-08-01 8:57 UTC (permalink / raw) To: Paolo Bonzini; +Cc: tromey, GCC Mailing List Paolo Bonzini wrote: >> For example, gdb has function that in the past could return null, but >> which now cannot. So, I'd like to find all places where the return >> result is checked. >> >> Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops. >> It is not ok to 'return' or 'goto' from inside the inner loop, as this >> causes hard-to-find bugs. So, it would be nice to find any place that >> tries this. >> >> Or, there is a data type in gdb that used to be freed using 'xfree', but >> which now requires a special function to be called instead. So, it >> would be nice to find any place where xfree is passed an argument of >> this type. > > MELT looks extremely cool! You may want to use this too, however: > > http://lwn.net/Articles/315686/ This is about Coccinelle so http://coccinelle.lip6.fr/ is a better link. Indeed, Tom Tromey might also try Coccinelle. However, MELT is a different beast: above all, it is tightly integrated inside GCC, and is designed & useful to write (or at least prototype) GCC passes (mostly in the middle end); while Coccinnelle is a tool unrelated to GCC (except for the input language, i.e. C). Since MELT works on GCC internal representations, it should be able to deal with all the source languages GCC is able to compile. So I would say that MELT is complementary to Coccinelle. BTW, people interested in static analysis for C (not C++ or Ada) might look at FramaC http://frama-c.cea.fr/ which is unrelated to GCC (except for its use of the preprocessor). I believe MELT could be best viewed as a tool for GCC plugins, either "analysis" plugins -which don't change the code and don't influence the GCC generated object code, or "transformation" or "optimisation" plugins, which do change the GCC code generation. For people able to review patches, my most desirable patch is http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html (a patch for gengtype). Currently, MELT can be compiled as a plugin to an unmodified GCC-trunk (ie 4.5) binary, but to compile MELT you need this patch (which improves the C code generated by gengtype in plugin mode). Regards. PS. In a few days, I'm leaving on vacation for almost 3 weeks without email access. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MELT tutorial on the wiki 2009-08-01 8:44 ` Paolo Bonzini 2009-08-01 8:57 ` Basile STARYNKEVITCH @ 2009-08-03 16:16 ` Tom Tromey 1 sibling, 0 replies; 20+ messages in thread From: Tom Tromey @ 2009-08-03 16:16 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Basile STARYNKEVITCH, GCC Mailing List >>>>> "Paolo" == Paolo Bonzini <bonzini@gnu.org> writes: Paolo> MELT looks extremely cool! You may want to use this too, however: Paolo> http://lwn.net/Articles/315686/ Yes, I'm also looking at Coccinelle and TreeHydra. As this is strictly a spare-time project, I am trying to find the approach that requires the least effort on my part. Coccinelle has the advantage that it is already packaged on Fedora. However, the documentation is not excellent (AFAICT there is a grammar and a bunch of examples, but nothing else) and that makes it difficult to use. Also it does not seem to handle GDB's heavily macroized code very well (maybe there's a way ... but again, the docs). TreeHydra looks very promising but it seems complicated to build. It wasn't clear which patches ought to be applied. I'm going to get it built one of these weeks... I was hoping that because all the code was on a branch, MELT would be the simplest to get working. Now I've spent more time on it than on the other two combined ;) Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* MELT tutorial on the wiki @ 2009-05-10 12:02 Basile STARYNKEVITCH 0 siblings, 0 replies; 20+ messages in thread From: Basile STARYNKEVITCH @ 2009-05-10 12:02 UTC (permalink / raw) To: GCC Mailing List Hello All I added a (still incomplete) MELT tutorial on the wiki: http://gcc.gnu.org/wiki/MELT%20tutorial It tells you how to do a hello world in MELT. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2009-08-23 17:57 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-29 15:52 MELT tutorial on the wiki Basile STARYNKEVITCH 2009-07-30 21:17 ` Tom Tromey 2009-07-31 6:27 ` Basile STARYNKEVITCH 2009-07-31 17:52 ` Tom Tromey 2009-07-31 20:16 ` Tom Tromey 2009-08-01 6:11 ` Basile STARYNKEVITCH 2009-08-01 7:06 ` Ralf Wildenhues 2009-08-02 14:57 ` Paolo Bonzini 2009-08-03 16:23 ` Tom Tromey 2009-08-03 19:21 ` Basile STARYNKEVITCH 2009-08-01 6:28 ` Dave Korn 2009-08-01 6:43 ` Basile STARYNKEVITCH 2009-08-01 6:58 ` Dave Korn 2009-08-03 16:12 ` Tom Tromey 2009-08-04 13:22 ` Dave Korn 2009-08-23 20:14 ` Ralf Wildenhues 2009-08-01 8:44 ` Paolo Bonzini 2009-08-01 8:57 ` Basile STARYNKEVITCH 2009-08-03 16:16 ` Tom Tromey -- strict thread matches above, loose matches on Subject: below -- 2009-05-10 12:02 Basile STARYNKEVITCH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).