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} ***
Re: GCC version bikeshedding
pins...@gmail.com writes: >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote: >> >> Ian Lance Taylor writes: >> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >>> break some people's existing scripts, as is also true of any other >>> decision we can make. >> >> Looking forward to gcc 10.0. :-) > > So are following what sun did? What does this have to do with sun? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
NightStrike writes: > On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote: >> >> pins...@gmail.com writes: >> >> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab > wrote: >> >> >> >> Ian Lance Taylor writes: >> >> >> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >> >>> break some people's existing scripts, as is also true of any other >> >>> decision we can make. >> >> >> >> Looking forward to gcc 10.0. :-) >> > >> > So are following what sun did? >> >> What does this have to do with sun? >> > > It's what sun did for Java and I think Solaris Did what? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[GSoC] outer-if expressions
Hi,
This patch adds support for outer-if expressions.
Couple of issues:
a) Doesn't interop with for-pattern, since we don't replace identifier
in c-expr yet,
and this gets more complicated with addition of outer-if.
b) I removed ifexpr-locations for now. I am not sure where to output
if-expr locations
when there are multiple if-exprs (one outer and one inner).
* genmatch.c (simplify::ifexpr): Remove.
(simplify::ifexpr_location): Likewise.
(simplify::simplify): Adjust to changes in simplify and
add parameter ifexpr_vec_.
(dt_simplify::gen_gimple): Adjust to changes in simplify.
(dt_simplify::gen_generic): Likewise.
(parse_if): New function.
(parse_pattern): Add call to parse_if.
* match.pd: Use outer-if for plus-minus patterns.
Thanks,
Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision 212928)
+++ gcc/genmatch.c (working copy)
@@ -298,18 +298,17 @@ e_operation::e_operation (const char *id
struct simplify {
simplify (const char *name_,
operand *match_, source_location match_location_,
- struct operand *ifexpr_, source_location ifexpr_location_,
- struct operand *result_, source_location result_location_)
+ struct operand *result_, source_location result_location_, vec ifexpr_vec_ = vNULL)
: name (name_), match (match_), match_location (match_location_),
- ifexpr (ifexpr_), ifexpr_location (ifexpr_location_),
- result (result_), result_location (result_location_) {}
+ result (result_), result_location (result_location_),
+ ifexpr_vec (ifexpr_vec_) {}
+
const char *name;
operand *match;
source_location match_location;
- struct operand *ifexpr;
- source_location ifexpr_location;
struct operand *result;
source_location result_location;
+ vec ifexpr_vec;
};
struct dt_node
@@ -554,8 +553,7 @@ lower_commutative (simplify *s, vecname, matchers[i], s->match_location,
- s->ifexpr, s->ifexpr_location,
- s->result, s->result_location);
+ s->result, s->result_location, s->ifexpr_vec);
simplifiers.safe_push (ns);
}
}
@@ -1452,14 +1450,21 @@ dt_simplify::gen_gimple (FILE *f)
fprintf (f, "captures[%u] = %s;\n", i, indexes[i]->get_name (opname));
}
- if (s->ifexpr)
- {
- output_line_directive (f, s->ifexpr_location);
- fprintf (f, "if (");
- s->ifexpr->gen_transform (f, NULL, true);
- fprintf (f, ")\n");
- fprintf (f, "{\n");
+ if (s->ifexpr_vec != vNULL)
+{
+ fprintf (f, "if (");
+ // we add in LIFO order, so traverse backwards
+ for (unsigned i = s->ifexpr_vec.length (); i; --i)
+ {
+ fprintf (f, "(");
+ s->ifexpr_vec[i - 1]->gen_transform (f, NULL, true);
+ fprintf (f, ")");
+ if (i > 1)
+ fprintf (f, " && ");
}
+ fprintf (f, ")\n");
+ fprintf (f, "{\n");
+}
output_line_directive (f, s->result_location);
if (s->result->type == operand::OP_EXPR)
@@ -1487,7 +1492,7 @@ dt_simplify::gen_gimple (FILE *f)
gcc_unreachable ();
fprintf (f, "return true;\n");
- if (s->ifexpr)
+ if (s->ifexpr_vec != vNULL)
fprintf (f, "}\n");
fprintf (f, "}\n");
@@ -1510,14 +1515,22 @@ dt_simplify::gen_generic (FILE *f)
fprintf (f, "captures[%u] = %s;\n", i, indexes[i]->get_name (opname));
}
- if (s->ifexpr)
- {
- output_line_directive (f, s->ifexpr_location);
- fprintf (f, "if (");
- s->ifexpr->gen_transform (f, NULL, false);
- fprintf (f, ")\n");
- fprintf (f, "{\n");
- }
+ if (s->ifexpr_vec != vNULL)
+{
+ fprintf (f, "if (\n");
+ // we add in LIFO order, so traverse backwards
+ for (unsigned i = s->ifexpr_vec.length (); i; --i)
+{
+ fprintf (f, "(");
+ s->ifexpr_vec[i - 1]->gen_transform (f, NULL, false);
+ fprintf (f, ")");
+ if (i > 1)
+fprintf (f, " && ");
+}
+ fprintf (f, ")\n");
+ fprintf (f, "{\n");
+}
+
output_line_directive (f, s->result_location);
if (s->result->type == operand::OP_EXPR)
@@ -1551,7 +1564,7 @@ dt_simplify::gen_generic (FILE *f)
else
gcc_unreachable ();
- if (s->ifexpr)
+ if (s->ifexpr_vec != vNULL)
fprintf (f, "}\n");
fprintf (f, "}\n");
@@ -2025,7 +2038,7 @@ parse_match_and_simplify (cpp_reader *r,
token = peek (r);
if (token->type != CPP_OPEN_PAREN)
-return new simplify (id, match, match_location, 0, 0, parse_op (r), token->src_loc);
+return new simplify (id, match, match_location, parse_op (r), token->src_loc);
eat_token (r, CPP_OPEN_PAREN);
@@ -2037,25 +2050,27 @@ parse_match_and_simplify (cpp_reader *r,
{
operand *result = parse_expr (r);
eat_token (r, CPP_CLOSE_PAREN);
- return new simplify (id, match, match_location, 0, 0, result, result_loc);
+ return new simplify (id, match, match_location, result, result_loc);
}
// (if c
Re: GCC version bikeshedding
On Sat, Jul 26, 2014 at 7:57 PM, Andreas Schwab wrote: > NightStrike writes: > >> On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote: >>> >>> pinskia writes: >>> >>> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote: >>> >> >>> >> Ian Lance Taylor writes: >>> >> >>> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >>> >>> break some people's existing scripts, as is also true of any other >>> >>> decision we can make. >>> >> >>> >> Looking forward to gcc 10.0. :-) >>> > >>> > So are following what sun did? >>> >>> What does this have to do with sun? >>> >> >> It's what sun did for Java and I think Solaris > > Did what? Cut the major version number. Solaris 2.9 was marketed as Solaris 9. Likewise for Solaris 2.10 and 2.11. They simply dropped the 2 from the version number Ciao! Steven
Re: GCC version bikeshedding
Steven Bosscher writes: > Cut the major version number. Solaris 2.9 was marketed as Solaris 9. > Likewise for Solaris 2.10 and 2.11. They simply dropped the 2 from the > version number Which has nothing to do with gcc. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
