On 6/15/19 9:45 PM, Gerald Pfeifer wrote:
On Sun, 15 Jul 2018, Basile Starynkevitch wrote:
Basile, should we generally remove this reference to GCC MELT?
Yes. I am no more working on MELT, but I did begin to work on its successor:
Sorry for the delay - I finally applied the patch below.
If
On 07/15/2018 07:12 AM, Basile Starynkevitch wrote:
On 07/14/2018 10:17 PM, Gerald Pfeifer wrote:
I noticed that http://gcc-melt.org now redirects to
http://www.gcc-melt.org which looks like a default,
and empty, Wordpress installation.
I went ahead and applied the patch below.
Basile
es. I am no more working on MELT, but I did begin to work on its successor:
https://github.com/bstarynk/bismon
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
On 06/07/2016 09:19 PM, Andrew Pinski wrote:
On Mon, May 23, 2016 at 5:26 AM, Basile Starynkevitch
wrote:
Hello All,
As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is
difficult (or tricky without using dirty tricks involving the GCC plugin
headers) to use GCCJIT to emit
alue from the GCCJIT
compiler.
The attached patch (relative to trunk svn 236583) is a first attempt to solve
that issue
(and also give ability to query some other magic numbers).
Proposed ChangeLog entry (in gcc/jit/)
2016-05-23 Basile Starynkevitch
* libgccj
tinuations.
Why an attribute? Attributes are on declarations. I think it should
better be some pragma like _Pragma(GCC tail cail, foo(x,y)) or some
builtin (or else some syntax extension like goto return foo(x,y); ...)
because what we really want is to annotate a particular call to be
tail-
ChangeLog entry
2015-07-16 Basile Starynkevitch
* jit-playback.c: Mention that it is in C++.
(new_rvalue_from_const ): New.
* jit-recording.c: Mention that it is in C++.
(recording::memento_of_new_rvalue_from_const ): New
instanciated template.
(memento_of_new_rvalue_
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
* dump_to_reproducer
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
Does this actually link and
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to GCCJIT.
It is bootstrapping, but I don't have any test cases
## gcc/jit/ChangeLog entry:
2015-07-15 Basile Starynke
atements ability would be backported to
GCC 5. (Its absence is IMHO a severe bug in GCCJIT, but perhaps GCC rules
forbid backporting new features, even when they correct a huge
deficiency and when the patch adding them is probably quite small).
Cheers.
--
Basile Starynkevitch ht
ed feature macros within libgccjit.h e.g:
#define LIBGCCJIT_HAVE_SWITCH_STATEMENT
for the benefit of client code that doesn't use configure
scripts.
Perhaps just exposing the major and minor version of the GCC supporting
that GCCJIT is enough (like it was done for plugins, e.g.
GC
ok at it, please! I'm sure my mistake is trivial, but
I cannot find it.
I really hope this would go into GCC 5.0 (and the delay is short),
because MELT http://gcc-melt.org/ is needing it.
Regards & thanks for your help.
--
Basile Starynkevitch http://starynkevitch.net/Basile/
On Wed, 2014-11-12 at 14:36 +0100, Basile Starynkevitch wrote:
> On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote:
> > > Most plugin don't need any configure, because they are instal
On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote:
> > Most plugin don't need any configure, because they are installed in
> > a version specific directory (like /usr/lib/gcc/x86_64-linux-gnu
On Wed, Nov 12, 2014 at 02:12:07PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 12, 2014 at 01:55:12PM +0100, Basile Starynkevitch wrote:
> > Hello All,
> >
> > Some plugins (including MELT, see http://gcc-melt.org/ for more)
> > are made of several C++ source file
bles the definition
of `gcc_version` when the preprocessor symbol GCCPLUGIN_SKIP_VERSION_DATA
is defined as 1 before #include "plugin-version.h"
### gcc/ChangeLog entry:
2014-11-12 Basile Starynkevitch
* configure.ac (plugin-version.h): Don't define version data
On Mon, 2014-10-20 at 13:54 -0400, David Malcolm wrote:
> Committed to branch dmalcolm/jit:
>
> pkg-config appears to be controversial, so don't provide a .pc file.
I would put it under contrib/; it is controversial, but some would like
to have it.
Cheers.
--
Basile
> s/are supporting/support/
> s/For an example of using such a pragma/For example/
>
Thanks for the review.
Committed revision 208660.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 9
y
2014-03-18 Basile Starynkevitch
* plugin.def: Improve comment for PLUGIN_INCLUDE_FILE.
* doc/plugins.texi (Plugin callbacks): Mention
PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense
On Sat, 2014-03-08 at 11:15 +0100, Basile Starynkevitch wrote:
> I am pinging again this documentation patch
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
> (pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on
> febµ.17th 2014)
and also pinged at
http://gc
Hello All,
I am pinging again this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
(pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on febµ.17th
2014)
gcc/ChangeLog entry
2014-03-08 Basile Starynkevitch
* doc/plugins.texi (Plugin
On Wed, 2014-03-05 at 15:00 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR requests beyond the already commited ones some further headers.
>
> Tested with make install, ok for trunk?
I am not authorized to approve that, but I hope it will be committed.
Cheers.
--
Basil
t; -ansi option. This file contains some other options like the -w and -Q
> options.
gcc is mostly a driver program. The real work happens in cc1 or cc1plus (which
is started by gcc). So you need to look inside gcc/toplev.c and gcc/*.opt
files....
Regards.
--
Basile STARYNKE
Hello All,
I am pinging this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
Dear all,
The attached patch to trunk svn.rev 207422 is slightly improving the
documentation
of plugins (notably the few features & bugfixes I have introduced in 4.9)
gcc/ChangeLog entry
2014-02-03 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Men
ks_full
should be edited, and another is the tiny fix on that function in
plugin.c
### gcc/ChangeLog entry
2013-11-19 Basile Starynkevitch
* plugin.def: Add comment about register_callback and
invoke_plugin_callbacks_full.
* plugin.c (register_callback, invo
correct the bug, I guess that I could apply it under the
"obvious bugfix" rule. Could you check that it works on your MacOSX?
Apologies for my mistake.
Thanks
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue d
Gnu Linux x86-64
systems...
Or is it some MacOSX specific bug? (BTW, I thought that GCC plugins
never worked on MacOSX or on Windows)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 B
On Tue, 2013-11-19 at 16:16 +, Joseph S. Myers wrote:
> On Tue, 19 Nov 2013, Basile Starynkevitch wrote:
>
> > Thanks for your attention. I am attaching a slightly improved patch
> > against trunk svn rev. 305009 (the improvements are removing the spurious
> > diff h
On Mon, Nov 18, 2013 at 10:50:10PM +, Joseph S. Myers wrote:
> On Mon, 18 Nov 2013, Basile Starynkevitch wrote:
>
> > @@ -43,6 +44,7 @@
> >TARGET_OPTF. */
> > #include "tm_p.h" /* For C_COMMON_OVERRIDE_OPT
that a file is included. This could happen
+several times. */
+ invoke_plugin_callbacks
+ (PLUGIN_INCLUDE_FILE,
+const_cast (ORDINARY_MAP_FILE_NAME (new_map)));
+}
+
if (new_map == 0 || (new_map->reason == LC_LEAVE && MAIN_FILE_P
(new_map)))
{
pch_cpp
__auto_type) and a similar semantics.
And I also like that feature, but it should be documented outside of the
support of since it is genuinely useful by itself (e.g. as
an alternative to typeof).
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} ***
some diagnostics here. */
invoke_plugin_callbacks (PLUGIN_FINISH, NULL);
+ diagnostic_finish (global_dc);
+
finalize_plugins ();
location_adhoc_data_fini (line_table);
if (seen_error () || werrorcount)
gcc/ChangeLog entry
2013-11-11 Basile Starynkevitch
* top
xtension
is non-sense; such files should have a .cc (or maybe .cpp or .cxx) extension,
not a .c extension.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opi
milar ones) will be accepted in 4.9
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} ***
issues, converting them to gengtype errors or runtime assertions.
> It also adds a handler for (E), turning this from a failure to
> compile bogus C to a specific error in gengtype.
>
> I'm bootstrapping/regtesting now.
> OK for trunk if that passes?
I don't have the
al_dc);
+
finalize_plugins ();
location_adhoc_data_fini (line_table);
if (seen_error () || werrorcount)
proposed gcc/ChangeLog entry
2013-10-01 Basile Starynkevitch
* toplev.c (toplev_main): Move PLUGIN_FINISH invocation before
diagnostic_finish.
#
I am not ent
On Fri, Sep 20, 2013 at 05:56:22PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 20, 2013 at 05:52:38PM +0200, Basile Starynkevitch wrote:
> > On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote:
> > > On 2013-09-16 04:19 , Basile Starynkevitch wrote:
> > > >
On Fri, Sep 20, 2013 at 09:49:34AM -0400, Diego Novillo wrote:
> On Mon, Sep 16, 2013 at 4:23 AM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I'm pinging again my small patch to accept = inside plugin arguments
> > http://gcc.gnu.org/ml/gcc-patches/201
On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote:
> On 2013-09-16 04:19 , Basile Starynkevitch wrote:
> >Hello all,
> >
> >I'm pinging the patch (of september 2nd) on
> >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
> >
> >
&
Hello All,
I'm pinging again my small patch to accept = inside plugin arguments
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00037.html
# gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch
* plugin.c (parse_plugin_ar
Hello all,
I'm pinging the patch (of september 2nd) on
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch
* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give
ange that it would be less optimized than the system's
operator new.
Perhaps we need an attribute `nonnullresult' which whould means that.
(we already the nonnull attribute for function arguments)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basi
Hello
I'm pinging my last month's patch
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
of August 07th 2013 to accept the = inside plugin arguments
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8,
gengtype.
FWIW, this patch is imported from melt-branch svn rev 202160.
gcc/ChangeLog entry
2013-09-02 Basile Starynkevitch
* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give fatal message when no
rules found.
###
Ok for
cessing all of it (i.e. every GTY-ed class
declaration), and have our gengtype successor plugin emit appropriate
#if in the generated C++ code.
Of course having gengtype replaced by a plugin requires such a plugin to
be developed and GCC maintainers to have access to some gcc...
Cheers
--
Bas
tive to trunk 201571 should solve the
issue.
# gcc/ChangeLog entry
2013-08-07 Basile Starynkevitch
* plugin.c (parse_plugin_arg_opt): Accept equal sign inside
plugin argument.
Comments are welcome. Ok for trunk?
Cheers
--
Basile STARYNKEVITCH http://star
putting __FILE__ and __LINE__ in
instances of opt_pass? I really hope that will go into 4.9!
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 mine, sont seulement les miennes} ***
e zillions of instances of
opt_pass) and would help a lot finding where (in which source file)
an actual pass is.
This is particularly useful for newbies writing plugins (which are
trying to add new passes). It takes a lot of time to them to find which
actual source file inside the compiler is
(like LLVM
is) is a
worthwhile goal, but I don't think that aiming that future library to be
multi-threadable
(or thread-friendly) is very realistic. At least, we should make the two goals
separate:
first, make GCC a library, then (and later) make that library thread friendly.
So I mi
plugin hooks for that purpose?
It might be a good idea, for back-end related plugins (which probably don't
exist today).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La R
GCC version 4.5.0 and
> > +later.
Maybe we should say that a later version is preferable.
IIRC 4.5 plugin support was not very good -it was more an experimental stage
than
anything else. I believe that we should not encourage people to write plugins
against
4.5.....
Cheers.
race, if
that helps you
(of course, I would prefer avoiding that)
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} ***
On Wed, Oct 03, 2012 at 01:02:44PM +0200, Basile Starynkevitch wrote:
> So I applied and I am proposing the following patch to gcc trunk 192031
> (Laurynas, I did take your remarks into account)
> # patch to trunk
> Index: gc
On Thu, Oct 04, 2012 at 07:26:23PM +0200, Richard Guenther wrote:
> On Thu, Oct 4, 2012 at 7:24 PM, Basile Starynkevitch
> wrote:
> > On Thu, Oct 04, 2012 at 06:51:35PM +0300, Laurynas Biveinis wrote:
> >> > 2012-10-03 Basile Starynkevitch
> >> >
> >
On Thu, Oct 04, 2012 at 06:51:35PM +0300, Laurynas Biveinis wrote:
> > 2012-10-03 Basile Starynkevitch
> >
> > * gengtype.c (walk_type): Emit mark_hook when inside a
> > struct of a union member.
>
> This is OK.
thanks, Committed revision 192
On Wed, Oct 03, 2012 at 01:02:44PM +0200, Basile Starynkevitch wrote:
> On Wed, Oct 03, 2012 at 12:21:02PM +0300, Laurynas Biveinis wrote:
> > Hello Basile -
> >
> > > 2012-10-02 Basile Starynkevitch
> > >
> > > * gengtype.c
On Wed, Oct 03, 2012 at 12:21:02PM +0300, Laurynas Biveinis wrote:
> Hello Basile -
>
> > 2012-10-02 Basile Starynkevitch
> >
> > * gengtype.c (walk_type): Emit mark_hook when inside a
> > struct of a union member.
>
> Can you send me off
ntry is:
2012-10-02 Basile Starynkevitch
* gengtype.c (walk_type): Emit mark_hook when inside a
struct of a union member.
####
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mob
arly as functionnal as the original one, so I'm proposing the
> attached patch that adds this probe under the contrib/ directory.
Thanks. I just commited svn rev 191773 on the MELT branch
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mob
agmas to add deprecation warnings to macros they define.
>
> Bootstrapped and tested on x86_64-redhat-linux-gnu, with no apparent
> regressions. Okay for trunk?
I can't approve your patch, but I find it useful and wish it would be accepted.
Cheers.
--
Basile STARYNKEVITCH
On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
> wrote:
> > On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> >> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> >
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I am pinging the patch
> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
> > below fo
tderr, "%s ",
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
### gcc/ChangeLog entry
2011-05-16 Basile Starynkevitch
* toplev.c (announce_function): Output newline periodically.
###
vailable bits. And perhaps even developers of other passes.
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 mine, sont seulement les miennes} ***
(!p) return nullptr;
where p is a formal argument.
Or perhaps I am misunderstanding what Marc is saying.
I would rather suggest using all the return statements to infer the type of the
function,
not only the first one.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
e
cc1 -v
inside an Emacs buffer (or agdb session inside Emacs).
The attached patch (backbported from the MELT branch, where it is very
useful) fixes this issue by adding a newline once every eight identifiers.
gcc/ChangeLog entry
2011-02-10 Basile Starynkevitch
* toplev.c
, they should be named
by options which are evocative of what the extension provides.]
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 min
Hello,
Regarding this shrink-wrapping patch, I would suggest to describe, in a
comments of one or two sentences, what shkink-wrapping means in the context
of GCC.
http://en.wikipedia.org/wiki/Shrink_wrap does not help much in understanding
that.
Cheers.
--
Basile STARYNKEVITCH http
On Fri, 30 Sep 2011 09:24:03 +0200
Tristan Gingold wrote:
>
> On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> > I believe that such an extension is useful on other systems, even when
> > their ABI don't
> > pass the number of arguments.
> >
>
usage?
And perhaps then such an extension might be trigerred by a flag which don't
even mention
DEC. Eg -fveryvariadic-extensions ?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faien
haps some plugins could install their signal handlers....
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} ***
Hello All
Gerald suggested me to submit a patch to the http://gcc.gnu.org/extensions.html
page about GCC MELT.
I am attaching it.
Gerald, if the patch is OK, could you please apply it?
I am very uneasy about CVS for the GCC website.
Regards.
--
Basile STARYNKEVITCH http
buffer.
This is *exactly* the same patch as
Pierre Vittet proposed in
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html
(but Pierre's patch has not been reviewed).
Perhaps the ChangeLog might also mention Pierre Vittet for that particular
patch???
Cheers.
--
Basile
plugin with current gcc 4.6.
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} ***
> Ok for trunk ?
I can't formally approve this patch, but I do hope it will be reviewed and
approved soon.
See http://gcc.gnu.org/ml/gcc-help/2011-09/msg00126.html
and http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html
and
http://groups.google.com/group/gcc-melt/browse_thread/thread/292
(ie when applying
that patch to rev 178154 of the MELT branch?
(I am investigating)
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,
that i explore this
> issue on my configuration.
Yes please. I don't understand why on my system the builds go till melt-stage3
while on
Pierre's machine it fails before melt-stage2, and we looked together (by IRC)
several
hours.
Cheers
PS Being on vacation, I probably won'
(don't use make -j, only a sequential make).
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 mine, sont seulement les miennes} ***
On Tue, 2 Aug 2011 10:46:38 +0200
Romain Geissler wrote:
> 2011/8/2 Basile Starynkevitch :
> > Please use capitals for macrovariables in
> > macrostrings
>
> Ok.
>
> Can i have more details about that: is it just a Melt convention or is
> it an implementation re
(melt_ptr_t) $DIS)}#)
instead of
+#{meltgc_new_split_string(melt_string_str($cs), ' ', (melt_ptr_t) $dis)}#)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
***
apply the global /precs/preds/ change (and
> >thus the iterator is renamed).
> >
> >Romain Geissler
> >
>
> Hello,
>
> I wrote the initial iterator and agree with your change. I guess
> Basile will commit it soon.
It is committed.
--
Basile STARYNKEVITCH
On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor wrote:
> Jakub Jelinek writes:
>
> > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> >> Basile Starynkevitch writes:
> >>
> >> > I have a similar issue in the MELT branch, and
On Thu, 21 Jul 2011 17:32:40 +0200
Romain Geissler wrote:
> I have just updated to the latest svn revision, and it seems you
> forgot to #include cpplib.h and langhooks.h.
Done. Committed revision 176577 of the MELT branch.
Thanks for spotting my mistake.
--
Basile STARYNKEVITCH
;4006 ||
defined(__cplusplus)
#include "c-family/c-pragma.h"
#else
#include "c-pragma.h"
#endif
And likewise in melt-run.proto.h
What do you think? (I really want the MELT plugin to be compilable on an
installed
gcc-4.6!)
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 mine, sont seulement les miennes} ***
ed=0.
I have a similar issue in the MELT branch, and I am passing to -frandom-seed
the md5sum
of relevant source files. With such a trick, the seed is reproducible from one
build to
the next one (of the exact same source tree), and does provide much more
randomness than
just using 0 all the time.
not sure it is the good way to go.
Maybe a better way would be to pass a -fmelt-plugin-arg-privatedir=your/dir/ to
MELT and
have it generate the .c, .pic.o, .so files inside.
Romain, you might try to call me tomorrow. It will be easier for both of use to
speak on
the phone & in Fren
> Romain Geissler
>
> --
> Message from the http://groups.google.com/group/gcc-melt group.
> About GCC MELT http://gcc-melt.org/ a high level domain specific language to
> code extensions to the Gnu Compiler Collection
--
Basile STARYNKEVITCH http://starynkevitch.n
86_64 red hat.
I am not authorized to approve that patch, but I really hope it will be
approved.
(I am guilty of not having gengtype being installed)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Fa
> Yes. With this patch, we build cc1plus at stage 1, and use it to build
> libstdc++ at stage 1, and use both to build stage 2.
I think that we might also want to have some easy & documented way to build the
stage1
directly with g++, assuming (or when) it is already availab
t;
> * melt/warmelt-base.melt (register_pragma_handler): new function.
Thanks. I committed it on the MELT branch. Committed revision 175962.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie,
Hello All,
The attached documentation patch is nearly trivial, I was tempted to apply it
without review.
### gcc/ChangeLog entry ###
2011-07-06 Basile Starynkevitch
* doc/plugins.texi (Building GCC plugins): gengtype needs its
gtype.state
### end gcc/ChangeLog entry
On Wed, Jul 06, 2011 at 04:02:48PM +0200, Richard Guenther wrote:
> On Wed, Jul 6, 2011 at 3:46 PM, Basile Starynkevitch
> wrote:
> > On Wed, Jul 06, 2011 at 03:21:47PM +0200, Richard Guenther wrote:
> >> On Wed, Jul 6, 2011 at 2:50 PM, Basile Starynkevitch
> >> wro
On Wed, Jul 06, 2011 at 03:21:47PM +0200, Richard Guenther wrote:
> On Wed, Jul 6, 2011 at 2:50 PM, Basile Starynkevitch
> wrote:
> >
> > I belive it can help to make plugin code more robust. A serious plugin
> > developper could then add in his plugin code so
tly only check for version compatibility at plugin dlopen
time, not at plugin build time!
I am attaching the diff file gccplugin_rev_configure_r175910.diff against
trunk 175910
### gcc/ChangeLog entry
2011-07-06 Basile Starynkevitch
* configure.ac (plugin-version.h): G
ovement might be to set the location (i.e. locnamv
in meltgc_read_from_val) to something which depends upon the string
rbuf. I have no idea if that would be useful.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, r
D_LIBDEPS)
+$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
#
How do you think gengtype should be built & installed as a user program?
I am very uneasy with gcc/Makefile.in, so I really need help about this.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/
Hello All,
I am pinging http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01524.html :
On Mon, 20 Jun 2011 21:34:44 +0200
Basile Starynkevitch wrote:
>
> The attached patch to trunk 175201 makes cc1, cc1plus, ... lto1 also
> search a language specific subdirectory.
>
> # gcc/
> > #ifdef HAVE_USER_TIME
> > /* Print user-mode time for this process. */
> > ### gcc/ChangeLog entry
> > 2011-06-25 Basile Starynkevitch
> >
> > * timevar.c (timevar_print): Increase width for display of timevar
> > name.
> > ##
1 - 100 of 156 matches
Mail list logo
