Re: How to default to -fno-math-errno on all FreeBSD targets
On Mon, Feb 7, 2011 at 9:37 PM, Andrew Pinski wrote: > On Mon, Feb 7, 2011 at 2:55 AM, Richard Guenther > wrote: >> Does FreeBSD ever set errno for malloc() calls? See PR47179 and >> PR42944 - which means it might require splitting the flag into a >> math piece and a general piece (or one covering just malloc & friends). > > The option's documentation (and the name itself) says it is a math > piece anyways. So I don't see why need to split it up? Because we (ab-)use it for malloc as well as there is no way for the Fortran frontend to specify it doesn't care for errno at all. Thus, we probably need a -fno-non-math-errno (ick). Richard. > -- Pinski >
Re: Broken bootstrap on Cygwin
On Mon, Feb 7, 2011 at 11:27 PM, FX wrote: >> GCC maintainers is this OK for your policy? > > Personally, I don't think it's a good thing to do: a secondary platform that > only supports the latest released version of said platform does not indicate > high stability. But it's up to the cygwin maintainers to decide, of course. > > However, the fact should be documented on the installation notes > (http://gcc.gnu.org/install/specific.html#x-x-cygwin) and probably on the > release notes as well, with something like "The GCC 4.6 series requires > Cygwin x.y.z or later". Indeed. Maybe also document a workaround (if possible), like "download fenv.h from this link and put it there". Richard. > FX >
Re: sparc-rtems recent test regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/11 12:47, Joel Sherrill wrote: > On 02/07/2011 01:46 PM, Jeff Law wrote: > On 02/07/11 11:51, Joel Sherrill wrote: On 02/07/2011 09:32 AM, Jeff Law wrote: On 02/02/11 07:19, Joel Sherrill wrote: >>> Hi, >>> >>> In the past few days, something has regressed >>> on the sparc. Revision 169143 only had 699 failures >>> and ~100 of those were LTO related. David Korn's >>> patch seems to have resolved those. Revision 169504 >>> has 2231 failures. Were you able to test whether or not the ira-costs.c patch was the cause of these problems? It's been problematical elsewhere and it wouldn't take much more than a nudge to for me to pull it given its ability to uncover latent problems. > This is for revision 169231. So it looks like that caused > the failures. > OK. I'm going to take a looksie. As long as it isn't something I've > already fixed or some dumb bug elsewhere, the plan is to pull the > ira-costs patch and revisit it in stage1. > >> If you need me to test something, just yell. Will do. What's the best way to test the sparc-rtems target? Do you use a sim? I've got access to sparcs via the gcc buildfarm, but that's about it. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUWJ+AAoJEBRtltQi2kC7+O8H/1+yMvSFGmdw1u1QlNLFb2DD 95bHWso3hpYXnwHr/QJV17UGWwwfRYCETmG3WHAYeqEZ3qO+/8hHlXeJ+m58u2Fw vyMDHSscw5gWFs/jKnZQj0xtEibTRSQtzug+HPR1YxKiB93xEDZfa7aV/hmBX/2z Oo8SffAa5vulyzC3FHZzz4Esgr6GEdL3aJbXT7QiyI0FZNrZ/WXUz9ejaTCNqrDu U1HMLLORt3x8XBAEcO/ktX16YyJHlvDZaTOXYr5+4Bnb/YXT6eufYaelHZwoUL/g ypRlMMN8lnq0gVuxT5etha7hatUIR5EEEjR2RwL++3MmbUHue/Oa5HqwEC46zmQ= =PAIv -END PGP SIGNATURE-
Re: sparc-rtems recent test regressions
On 02/08/2011 09:34 AM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/11 12:47, Joel Sherrill wrote: On 02/07/2011 01:46 PM, Jeff Law wrote: On 02/07/11 11:51, Joel Sherrill wrote: On 02/07/2011 09:32 AM, Jeff Law wrote: On 02/02/11 07:19, Joel Sherrill wrote: Hi, In the past few days, something has regressed on the sparc. Revision 169143 only had 699 failures and ~100 of those were LTO related. David Korn's patch seems to have resolved those. Revision 169504 has 2231 failures. Were you able to test whether or not the ira-costs.c patch was the cause of these problems? It's been problematical elsewhere and it wouldn't take much more than a nudge to for me to pull it given its ability to uncover latent problems. This is for revision 169231. So it looks like that caused the failures. OK. I'm going to take a looksie. As long as it isn't something I've already fixed or some dumb bug elsewhere, the plan is to pull the ira-costs patch and revisit it in stage1. If you need me to test something, just yell. Will do. What's the best way to test the sparc-rtems target? Do you use a sim? I've got access to sparcs via the gcc buildfarm, but that's about it. We use the sis/erc32 simulator in gdb. You have to build binutils, gdb, gcc/newlib, and rtems to be able to test. I am happy to help you offline with setting it up. But it is probably quicker for you to send me a patch and let me push it through the (smaller than GCC's) RTEMS build farm. :) jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUWJ+AAoJEBRtltQi2kC7+O8H/1+yMvSFGmdw1u1QlNLFb2DD 95bHWso3hpYXnwHr/QJV17UGWwwfRYCETmG3WHAYeqEZ3qO+/8hHlXeJ+m58u2Fw vyMDHSscw5gWFs/jKnZQj0xtEibTRSQtzug+HPR1YxKiB93xEDZfa7aV/hmBX/2z Oo8SffAa5vulyzC3FHZzz4Esgr6GEdL3aJbXT7QiyI0FZNrZ/WXUz9ejaTCNqrDu U1HMLLORt3x8XBAEcO/ktX16YyJHlvDZaTOXYr5+4Bnb/YXT6eufYaelHZwoUL/g ypRlMMN8lnq0gVuxT5etha7hatUIR5EEEjR2RwL++3MmbUHue/Oa5HqwEC46zmQ= =PAIv -END PGP SIGNATURE- -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Broken bootstrap on Cygwin
Sorry all, been offline for a couple of days after my pc blew up. On 07/02/2011 20:50, Angelo Graziosi wrote: > I do not understand the logic here: break GCC trunk for something that > hasn't been yet released. But GCC trunk has not been released either yet! GCC trunk and Cygwin trunk are in synch. The next released versions of both will work together. People working on trunk occasionally need to use trunk versions of other things such as binutils or glibc to get the full functionality, and there's always --disable-libquadmath for those who don't want to. cheers, DaveK
GCC 4.6 performance regressions
Hi, The following article has a fairly comprehensive set of benchmarks run against all the current stable releases of GCC as well as 4.6.0. http://www.phoronix.com/scan.php?page=article&item=intel_avx_gcc&num=1 There are some great results for 4.6.0 in there, which is very good news (congratulations!). However there are also some performance regressions, some of which are fairly significant. I have a few questions regarding these regressions; 1. Can any of these results be logged as 4.6 regressions in bugzilla, or are they too general as they stand to be of any use to anyone? 2. If not, any advice on how I can break these up into smaller chunks that would be of use? 3. Is there a single person assigned to looking at performance issues, or is this handled by the community as a whole? 4. Is there a benchmark suite similar to the test suite, that these benchmarks could be added to? Thanks, Tony
Re: Broken bootstrap on Cygwin
On 08/02/2011 11:07, Richard Guenther wrote: > On Mon, Feb 7, 2011 at 11:27 PM, FX wrote: >>> GCC maintainers is this OK for your policy? >> Personally, I don't think it's a good thing to do: a secondary platform >> that only supports the latest released version of said platform does not >> indicate high stability. But it's up to the cygwin maintainers to decide, >> of course. >> >> However, the fact should be documented on the installation notes >> (http://gcc.gnu.org/install/specific.html#x-x-cygwin) and probably on the >> release notes as well, with something like "The GCC 4.6 series requires >> Cygwin x.y.z or later". > > Indeed. Maybe also document a workaround (if possible), like "download > fenv.h from this link and put it there". It needs the actual support routines from the Cygwin DLL as well as the header file. But yes, I will write a patch for the requirements page. Shouldn't libquadmath have an autoconf test for fenv.h? Or otherwise not be unconditionally enabled by default? cheers, DaveK
Re: GCC 4.6 performance regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/08/11 09:08, Tony Poppleton wrote: > Hi, > > The following article has a fairly comprehensive set of benchmarks run > against all the current stable releases of GCC as well as 4.6.0. >http://www.phoronix.com/scan.php?page=article&item=intel_avx_gcc&num=1 > > There are some great results for 4.6.0 in there, which is very good > news (congratulations!). However there are also some performance > regressions, some of which are fairly significant. > > I have a few questions regarding these regressions; > 1. Can any of these results be logged as 4.6 regressions in bugzilla, > or are they too general as they stand to be of any use to anyone? They're way too general. Not to mention the lack of information in the article necessary to repeat the results. > 2. If not, any advice on how I can break these up into smaller chunks > that would be of use? Well, ideally it'll be a small number of functions or files that account for the difference. So the first step would be to mix and match objects to see if there's a file/function which accounts for the changes. Note this doesn't always work and subtle changes like cache and tlb behaviour can make the results unpredictable. Even with those caveats, it's a place to start. > 3. Is there a single person assigned to looking at performance issues, > or is this handled by the community as a whole? Community as a whole. > 4. Is there a benchmark suite similar to the test suite, that these > benchmarks could be added to? We don't have a public benchmark suite. Several organizations who work on GCC have benchmark suites such as SPEC that are used to test & evaluate optimizations. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUX2mAAoJEBRtltQi2kC76QUIALy+sIPi9FLabPnMo8Jyj/1Y k2zcZWxuaXOTXK42j1OsoN31dttLxCaBPgQIPCJBQxGLCgwjkfs1Kjdi0/su2AAN irByqCkxPKWjfLYRtiNQv3Qw1av5cF25KUKf1Xo5hJJCUUjhwWiC5XfWduMoVZZQ JNov2AWm30B+Pp+JIeDGL7T/Du2Dn3NfP33l4BEXJaSVW56AWpBTzu02w352gqwE Vi/E0897s5U0Pf1Ou4b7yPxByOcgLVv0zk1B3qs3MRAQaG9pco6VeLcM0yeUQ2Y2 BgQpHvm6a54rdeD1z/QCuDyJLPl+0TSx4BFJUPio7XeYjqp68CNanbdfmCluOAk= =A3Tq -END PGP SIGNATURE-
Re: sparc-rtems recent test regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/08/11 08:43, Joel Sherrill wrote: > What's the best way to test the sparc-rtems target? Do you use a sim? > I've got access to sparcs via the gcc buildfarm, but that's about it. > >> We use the sis/erc32 simulator in gdb. > >> You have to build binutils, gdb, gcc/newlib, and rtems >> to be able to test. I am happy to help you offline >> with setting it up. But it is probably quicker for >> you to send me a patch and let me push it through >> the (smaller than GCC's) RTEMS build farm. :) Well, I did manage to trigger a couple regressions on the sparc native build using the farm, so I'll focus on those first and hope they're the root cause of the rtems issue. Once I've got something for you to spin, I'll pass it along. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUZr2AAoJEBRtltQi2kC70CUH/092x5HBWvbpcCB5Dcp7aJPf sDXy1kfloH5Mm6ffuaORVDRpMvoxPYn20XcsoM8Nl6yHJa3EXmC97SfignjJ3PK/ dC3FpAkZ/zYLgnnLzT+B05ClFWd1W3lZzESD1010g/ohASNnL44xTxPBAOjHV48q cTv0UvdvpuAc+Bi6jhaL7gG0EnovI9SiTOABRhX5JKnWcZRv1NADnAuZtcXGE2Um JE2mjS1dtVPLqLr/wQ4FmIwBWCW+goyCMUvTZdgYX5C25sqks5QzJ8jNPgFnZ9Q5 IUEfI2QNEEHs0DRFE0h3LW19h1XZCel42SSeJJqL4pJZzZ0NByaJgtF+IDO95SE= =wYQp -END PGP SIGNATURE-
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On 8 February 2011 09:47, Jonathan Wakely wrote: > On 6 February 2011 23:57, Gerald Pfeifer wrote: >> On Mon, 14 Jun 2010, Jonathan Wakely wrote: >> And wouldn't it be appropriate to remove doc/xml/gnu/fdl-1.2.xml now >> that you have added fdl-1.3.xml? > Possibly. We still have gpl-2.0.xml there, which doesn't seem to be > included. I followed that example. If you are not using GPL 2.0 nor FDL 1.2 anymore in libstdc++ (and we should not be using these two anymore in all of GCC), we should remove them. Would you mind doing that or should I give it a try? >>> I can do that, assuming no objections from the other maintainers. >> >> Hmm, I see that these two are still in there. We should not be >> using them anymore. Would you mind removing them, or do you see >> a problem? >> >> (It would be good to make the same change for GCC 4.5 as well.) >> >> Thanks, >> Gerald > > Done for trunk, r169915, like so: > > 2011-02-08 Jonathan Wakely > > * doc/xml/gnu/fdl-1.2.xml: Remove. > * doc/xml/gnu/gpl-2.0.xml: Remove. > * doc/Makefile.am: Update. > * doc/Makefile.in: Regnerate. > > Tested with 'make doc-html' > > I'll do the same for the 4.5 branch later today. In rev 169944 I've now removed gpl-2.0.xml from the 4.5 branch (we only have fdl-1.2 there, not 1.3, so I left that) 011-02-08 Jonathan Wakely * doc/xml/gnu/gpl-2.0.xml: Remove. * doc/Makefile.am: Update. * doc/Makefile.in: Regenerate. I've also fixed the "Regnerate" typo in my previous ChangeLog entry.
Re: How to default to -fno-math-errno on all FreeBSD targets
On Tue, Feb 08, 2011, Richard Guenther wrote: > On Mon, Feb 7, 2011 at 9:37 PM, Andrew Pinski wrote: > > On Mon, Feb 7, 2011 at 2:55 AM, Richard Guenther > > wrote: > >> Does FreeBSD ever set errno for malloc() calls? See PR47179 and > >> PR42944 - which means it might require splitting the flag into a > >> math piece and a general piece (or one covering just malloc & friends). > > > > The option's documentation (and the name itself) says it is a math > > piece anyways. So I don't see why need to split it up? > > Because we (ab-)use it for malloc as well as there is no way for the > Fortran frontend to specify it doesn't care for errno at all. Thus, > we probably need a -fno-non-math-errno (ick). FreeBSD does set errno in malloc(), but does not ship with the Fortran frontend. The undocumented abuse of -fno-math-errno to affect gcc's model for malloc() sounds insidious.
Re: GCC 4.6 performance regressions
What are the base option set used in all the comparison? O2, O3? Some of the build time results look weired -- e.g., adding -march speeds up *compile time* by 35%. David On Tue, Feb 8, 2011 at 8:08 AM, Tony Poppleton wrote: > Hi, > > The following article has a fairly comprehensive set of benchmarks run > against all the current stable releases of GCC as well as 4.6.0. > http://www.phoronix.com/scan.php?page=article&item=intel_avx_gcc&num=1 > > There are some great results for 4.6.0 in there, which is very good > news (congratulations!). However there are also some performance > regressions, some of which are fairly significant. > > I have a few questions regarding these regressions; > 1. Can any of these results be logged as 4.6 regressions in bugzilla, > or are they too general as they stand to be of any use to anyone? > 2. If not, any advice on how I can break these up into smaller chunks > that would be of use? > 3. Is there a single person assigned to looking at performance issues, > or is this handled by the community as a whole? > 4. Is there a benchmark suite similar to the test suite, that these > benchmarks could be added to? > > Thanks, > Tony >
Re: GCC 4.6 performance regressions
On Tue, Feb 8, 2011 at 16:14, Xinliang David Li wrote: > What are the base option set used in all the comparison? O2, O3? Some The flags are those set by the Makefiles of the different benchmarks (as downloaded from the web). Setting different flags with CFLAGS=... is painful. > of the build time results look weired -- e.g., adding -march speeds up > *compile time* by 35%. Because phoronix uses make -j the compile times are highly random. Sebastian
gcc-4.4-20110208 is now available
Snapshot gcc-4.4-20110208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 169947 You'll find: gcc-4.4-20110208.tar.bz2 Complete GCC (includes all of below) MD5=24963736f68c4516f07b010b8e09626a SHA1=cfa628ab4041ff63eed5bf6bbbf18a7db7f501e4 gcc-core-4.4-20110208.tar.bz2C front end and core compiler MD5=c544ca79f0285eedb4d158659de7e69e SHA1=f441e98bb3d13dcbf42f2af280ffb8a3c64acdc7 gcc-ada-4.4-20110208.tar.bz2 Ada front end and runtime MD5=06bac23376fb99fcd979daff841c7b72 SHA1=345ebc04bd535f788c4ba4918172fc9abf23b48b gcc-fortran-4.4-20110208.tar.bz2 Fortran front end and runtime MD5=0d74889ea1175ca91f788245d554b5ec SHA1=5434ac7b6eee10dc1027c5a7f64d64b7e3bc9b33 gcc-g++-4.4-20110208.tar.bz2 C++ front end and runtime MD5=c63c21fcd76b33466a590026d60bae21 SHA1=1675aea848fde49db69aca81a98a859ca3a8ab6f gcc-go-4.4-20110208.tar.bz2 Go front end and runtime MD5=be15caec65024a405fe38438507f9a8f SHA1=c5fdaf7423c6df489ce532f78d52cab86a6e6f56 gcc-java-4.4-20110208.tar.bz2Java front end and runtime MD5=c86611552328e6ce53fbada1c835a8a0 SHA1=f8011c2d418a156445cc89fcf7556aef7644137c gcc-objc-4.4-20110208.tar.bz2Objective-C front end and runtime MD5=108f98c7026d5a4f6cd521c6109f6242 SHA1=3d43190abb6f4f5c677a0d254852902d6ded1066 gcc-testsuite-4.4-20110208.tar.bz2 The GCC testsuite MD5=397157581690b9dbe4b8318f15f73e1b SHA1=b8de168414bdb3b9e0615921a9dd580e7067b9eb Diffs from 4.4-20110201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 4.6 performance regressions
On 8 February 2011 22:49, Sebastian Pop wrote: > > Because phoronix uses make -j the compile times are highly random. Don't they know how to use 'time' to measure something more useful? I wouldn't be entirely surprised, last time I looked they didn't seem to know to use --enable-checking=release when comparing compile time of snapshots against releases.
Re: GCC 4.6 performance regressions
Jonathan Wakely writes: >> Because phoronix uses make -j the compile times are highly random. > > Don't they know how to use 'time' to measure something more useful? > I wouldn't be entirely surprised, last time I looked they didn't seem > to know to use --enable-checking=release when comparing compile time > of snapshots against releases. While I appreciate Phoronix as a booster site, their benchmarking practice often seems very dodgy; I'd take the results with a large grain of salt -miles -- .Numeric stability is probably not all that important when you're guessing.
Re: GCC 4.6 performance regressions
> While I appreciate Phoronix as a booster site, their benchmarking > practice often seems very dodgy; I'd take the results with a large grain > of salt The main reason I posted the link in the first place was because it was reflecting my own emperical evidence for the application I am working on; the march/mtune flags (on various corei* cpus) are actually detrimental to performance (albeit by at most 10% - but still, not the performance boost I was hoping for). I had been trying for the last few weeks to strip down my application into a mini-benchmark I could create a PR out of, however it is tougher than expected and was hoping the Phoronix article was going to offer a quicker route to finding performance regressions than my code - as their coverage was a lot wider. Anyway, apparently this is not the case, so back to my original work... Would it not be in the best interests for both GCC and Phoronix to rectify the problems in their benchmarks? Could we not contact the authors of the article and point out how they can make their benchmarks better? I would be happy to contact them myself, however I think it would be far more effective (and valid) coming from a GCC maintainer. Points they have apparently missed so far are; - clarify which compiler flags they are using - don't run make -j when looking at compile times - ensure they are using --enable-checking=release when benchmarking a snapshot - in general, as much information as possible as to their setup and usage, to make the results easily repeatable Out of interest, has their been much communication in the past between GCC and Phoronix to address any of these issues in their previous benchmarks? Tony
Re: Building Secondary Languages After Newlib is Installed
On Fri, 28 Jan 2011, Joel Sherrill wrote: > This almost works but libstdc++-v3/configure.ac explicitly > checks $with_newlib to trip some AC_DEFINE's which have > to be tripped to build. I have a patch attached that logically > says if on target X, then you are always using newlib so > if you have "with_newlib" or "use_newlib", then set the > AC_DEFINE's. There may be a better way to know if the > library installed is newlib. > > So if --without-newlib is supposed to do the trick, then > it almost works. I can build Ada, Go, and C++ with > --without-newlib and this patch or something similar > but better. It looks like libstdc++-v3 mistakenly uses with_newlib to mean that the target uses newlib, not just that newlib is being built in this tree (which is how toplevel configure uses it). brgds, H-P
Re: defining add in a new port
On Fri, 28 Jan 2011, Jean-Marc Saffroy wrote: > (define_constraint "I" > "Signed 6-bit integer constant for binops." > (and (match_code "const_int") >(match_test "IN_RANGE (ival, -24, 32)"))) > > (define_register_constraint "A" "ADDR_REGS" > "The address registers.") > > (define_register_constraint "D" "DATA_REGS" > "The general (data) registers.") > > (define_predicate "reg_or_18bit_signed_operand" > (if_then_else (match_code "const_int") > (match_test "IN_RANGE (INTVAL (op), -(1 << 17), (1 << 17) - 1)") > (match_operand 0 "register_operand"))) > > (define_insn "adddi3" > [(set (match_operand:DI 0 "register_operand" "=D,D,A") > (plus:DI >(match_operand:DI 1 "register_operand" "%0,0,0") >(match_operand:DI 2 "reg_or_18bit_signed_operand" "I,D,n")))] > "" > "@ >addi %0, %2 >add%0, %2 >adda %0, %2") > It seems I was expecting too much intelligence from reload, or I didn't > give enough hints. JFTR (after reading subsequent messages and good pragmatic advice), I think you're working around a bug in gcc; your adddi3 should work as-is above. Reload may create suboptimal sequences, but it should always create working code. Not that we can do much about it, the port not in the tree and all, but perhaps later. There are recent-ish changes in this area (i.e. fp-sp elimination), fixing bugs exposed by other ports, so try updating your tree too. brgds, H-P
MELT plugin: test fopen
Hello, I would like to present you a small plugin, which could be a good exemple of a MELT use case. This plugin allows to monitor that after every call to the fopen function, we have a test on the pointer returned by fopen (monitoring that it is not null). It creates a pass after SSA and works on gimple. It firstly matchs the gimple_call on fopen and save the tree corresponding to the FILE *. Then we check that the next instruction is a gimple_cond between the saved tree and the NULL ptr. When no test are found, the following error is returned: "test_fopen_cfile.c:35:11: warning: fopen not followed by a test on his returned pointer [enabled by default]" I think MELT is particulary adaptated when we have to match tree or gimples like I do here. For the moment I have only used it on small test file. I will try to see what it gives on a more realistic small to medium application. The code can be find on github: https://github.com/Piervit/GMWarn . The idea is to add more plugins. If you have some ideas or remarks, I am interested (however I still have to learn a lot from both GCC and MELT). If you try the code you will need to use the GCC MELT branch (or there is some changes to do in the Makefile to have it with MELT as plugin). Regards!
