Ann: MELT plugin 0.9.8 release for GCC 4.6, 4.7 & future 4.8
Dear All,
It is my pleasure to announce the MELT plugin 0.9.8 for GCC 4.6, 4.7 & future
4.8
Download
http://www.gcc-melt.org/melt-0.9.8-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
a gzipped source tarball of 5377928 bytes of md5sum
6c0721202857c44a8edb1ae2252605e8 extracted from MELT branch svn rev. 194693
on december 22nd 2012.
MELT is a high-level domain specific language to extend the GCC compiler.
See http://gcc-melt.org/ for more. Notice that the web site gcc-melt.org has
been revamped and contains much more information than before (and more tutorial
information
as web pages, even if that is still incomplete).
Download
http://www.gcc-melt.org/melt-0.9.8-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
If you wan a two-page printable leaflet about MELT download
gcc-melt.org/gcc-melt-sheet.pdf
NEWS for 0.9.8 MELT plugin for GCC 4.6 & 4.7 & future 4.8
[[december, 22th, 2012]]
Language improvements
=
* The LET syntax accepts bindings with the :auto ctype-annotation, like e.g.
(let ( (:auto four (+i 2 2)) )
(debug "four=" four))
the ctype is the obtained by the expression defining that binding
i.e. (+i 2 2) it the above example which is of ctype_long.
The default ctype annotation -which used to be :value- is now :auto
this change is upward compatible but is very significant.
* BOX-ing and CONSTANT_BOX-ing syntactic constructs
The (BOX ) syntax makes a mutable value boxing the given
stuff. So for example (BOX (+i 2 1)) is the same
as (MAKE_INTEGERBOX DISCR_INTEGER (+i 2 1))
The (CONSTANT_BOX ) syntax makes a constant value boxing the
given stuff. So for example (CONSTANT_BOX 1) is the same as
the expression (MAKE_INTEGERBOX DISCR_CONSTANT_INTEGER 1)
* UNBOX-ing syntactic construct
The (UNBOX ) is a convenient way to unbox values. For example
the expression (UNBOX :TREE V) is the same as (TREE_CONTENT V)
Runtime improvements
A new evalfile mode is available to evaluate expressions from a
file (default is standard input).
The evaluating modes are diplaying the last evaluated expression
using the debug depth parameter, which can be set with
-fplugin-arg-melt-debug-depth=10 program argument.
C-types have now autoboxing fields. Discriminants for constant
boxing of stuff have been added, notably
DISCR_CONSTANT_BASIC_BLOCK, DISCR_CONSTANT_EDGE,
DISCR_CONSTANT_GIMPLE, DISCR_CONSTANT_GIMPLE_SEQ,
DISCR_CONSTANT_LOOP, DISCR_CONSTANT_TREE
Vector from GCC 4.8 are now possible inside MELT.
A melt_intern_cstring function is available in C to intern
arbitrary null-terminated strings.
The melt-module.mk makefile is accepting the
GCCMELT_MODULE_VERBOSE_BUILD variable.
Several primitives have been added.
* Numerous bug fixes.
Comments are welcome, notably on the gcc-m...@googlegroups.com list.
I strongly invite every person downloading MELT to subscribe & read that list.
Merry Christmas and Happy New Year to everyone.
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: cselib_record_set breaks due to auto_inc_dec
On Dec 20, 2012, "Paulo Matos" wrote: > This doesn't look sensible to me (but I might be overlooking a reason why we > want to do so) in the context of cselib_record_sets, however, I think > cselib_record_sets should instead have the patch applied: > - for_each_inc_dec (&insn, cselib_record_autoinc_cb, &data); > + for_each_inc_dec (&body, cselib_record_autoinc_cb, &data); Yeah, that makes sense. Walking over REG_NOTES was surely unexpected to me. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: cloog/isl version update for gcc 4.8
On Fri, Dec 21, 2012 at 5:39 PM, Jack Howarth wrote:
> On Fri, Dec 21, 2012 at 05:06:46PM +0100, Richard Günther wrote:
>> Jack Howarth wrote:
>>
>> >Tobi,
>> >Can you update the isl and cloog tarballs in the gcc infrastructure
>> >directory
>> >to the new isl 0.11.1 and cloog 0.18.0 releases from...
>> >
>> >ftp://ftp.linux.student.kuleuven.be/pub/people/skimo/isl//isl-0.11.1.tar.bz2
>> >http://www.bastoul.net/cloog/pages/download/cloog-0.18.0.tar.gz
>> >
>> >It looks like config/isl.m4 needs to be modified to understand MAJOR,
>> >MINOR, REVISION
>> >for the isl 0.11.1 version numbering.
>>
>> I don't think we need to require the new versions as the old ones work just
>> fine. The ils check also works with 0.11 for me.
>>
>> Richard.
>
> Richard,
>The main issue is that the test in configure is brain-dead and demands an
> explicit version.
Hm? It perfectly works with isl-0.11 for me.
> This is a problem since llvm 3.2 will now ship with polly support that
> requires the newer version
> and this polly can be called from within dragonegg. So by refusing to
> synchronize to the newer
> cloog/isl releases (which cause no regressions in the graphite testsuite), we
> are forcing
> distributions to patch FSF gcc 4.8 to work around this. Refusing to update
> cloog/isl seems like
> being unnecessarily obstinate on this.
If it doesn't work then patch the check to allow also 0.11[.1].
Richard.
>Jack
>>
>> >Index: configure.ac
>> >===
>> >--- configure.ac (revision 194661)
>> >+++ configure.ac (working copy)
>> >@@ -1607,7 +1607,7 @@ if test "x$with_isl" != "xno" &&
>> > dnl with user input.
>> > ISL_INIT_FLAGS
>> > dnl The minimal version of ISL required for Graphite.
>> >- ISL_CHECK_VERSION(0,10)
>> >+ ISL_CHECK_VERSION(0,11,1)
>> > dnl Only execute fail-action, if ISL has been requested.
>> > ISL_IF_FAILED([
>> >AC_MSG_ERROR([Unable to find a usable ISL. See config.log for
>> >details.])])
>> >@@ -1621,7 +1621,7 @@ if test "x$with_isl" != "xno" &&
>> > dnl
>> > dnl If we use CLooG-Legacy, the provided version information is
>> > dnl ignored.
>> >-CLOOG_CHECK_VERSION(0,17,0)
>> >+CLOOG_CHECK_VERSION(0,18,0)
>> >
>> > dnl Only execute fail-action, if CLooG has been requested.
>> > CLOOG_IF_FAILED([
>> >Index: config/isl.m4
>> >===
>> >--- config/isl.m4(revision 194661)
>> >+++ config/isl.m4(working copy)
>> >@@ -89,13 +89,13 @@ AC_DEFUN([ISL_REQUESTED],
>> > ]
>> > )
>> >
>> >-# _ISL_CHECK_CT_PROG(MAJOR, MINOR)
>> >+# _ISL_CHECK_CT_PROG(MAJOR, MINOR, REVISION)
>> > #
>> > # Helper for verifying ISL compile time version.
>> > m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
>> > [#include
>> >#include ],
>> >- [if (strncmp (isl_version (), "isl-$1.$2", strlen ("isl-$1.$2")) !=
>> >0)
>> >+ [if (strncmp (isl_version (), "isl-$1.$2.$3", strlen
>> >("isl-$1.$2.$3")) != 0)
>> > return 1;
>> >])])
>> >
>> >@@ -115,9 +115,9 @@ AC_DEFUN([ISL_CHECK_VERSION],
>> > LIBS="${_isl_saved_LIBS} -lisl"
>> > echo $CFLAGS
>> >
>> >-AC_CACHE_CHECK([for version $1.$2 of ISL],
>> >+AC_CACHE_CHECK([for version $1.$2.$3 of ISL],
>> > [gcc_cv_isl],
>> >- [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
>> >+ [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2,$3)],
>> > [gcc_cv_isl=yes],
>> > [gcc_cv_isl=no],
>> > [gcc_cv_isl=yes])])
>> >
>> >seems to work fine. Thanks in advance.
>> > Jack
>>
>>
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: How to tell that a compiler test result is from a branch?
On Fri, Dec 21, 2012 at 1:09 AM, David Daney wrote: > The last time I checked, gcc/REVISION is only set to the proper value by > running contrib/gcc_update. Right. Well, that makes things easy :-) Vlad, I've set up auto-testers for the lra-branch on gcc110 (powerpc64) and gcc66 (ia64). They run within 24 hours after something changes on the lra-branch, and post test results to gcc-testresults if build+test was successful. I'll watch the testers and report build failures manually here. Ciao! Steven
gcc-4.7-20121222 is now available
Snapshot gcc-4.7-20121222 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121222/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 194699 You'll find: gcc-4.7-20121222.tar.bz2 Complete GCC MD5=16678f187a917fb5cbd5988aa5c847dd SHA1=0383642a67df38a0ec9a56095f0f2f4cf896554f Diffs from 4.7-20121215 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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: How to tell that a compiler test result is from a branch?
On Sat, Dec 22, 2012 at 5:15 PM, Steven Bosscher wrote: > Vlad, I've set up auto-testers for the lra-branch on gcc110 > (powerpc64) and gcc66 (ia64). They run within 24 hours after something > changes on the lra-branch, and post test results to gcc-testresults if > build+test was successful. I'll watch the testers and report build > failures manually here. Hi Vlad, With a little help from Pinski, there's now also a mipsisa64 lra tester on gcc110. It's building a combined tree cross from powerpc64 to mipsisa64 for c,c++ and posts results to gcc-testresults. I'll be reporting any failures from this tester here also. Ciao! Steven
