2011-06-06 Basile Starynkevitch
* doc/plugins.texi (Loading plugins): Plugins are also
seeked in a front-end specific subdirectory.
(Plugin callbacks): lto1 plugins can't register pragma handlers.
* plugin.c: Update copyright year.
(PLUGIN_FILE_S
htly improved the code itself, by
informing the user with more details when a short-named plugin can't be
loaded.
## gcc/ChangeLog entries ##
2011-06-07 Basile Starynkevitch
* doc/plugins.texi (Loading plugins): Plugins are also
sought in a fro
it is not a big vector in practice.
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} ***
ttet for his first accepted patch to trunk.
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} ***
In
-20 Basile Starynkevitch
* plugin.c: Update copyright year.
(PLUGIN_FILE_SUFFIX): New macro.
(add_new_plugin): Short-named plugins are also searched in a
language-specific sub-directory.
* doc/plugins.texi (Loading Plugins): Document how short-named
seperator.
[notice that I changed the ChangeLog comment above]
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340
lish words (perhaps with a prefix for their module). Gtk naming
conventions is IMHO easier for newbies than GCC ones.
I also agree that tree-dfa.c is more confusing than attribs.c, but I
still welcome the patch proposed by Nicola Pero.
Regards.
--
Basile STARYNKEVITCH http://starynkev
GCC by a significant, predictable, & measurable
amount. Sadly, GCC is almost nearly good enough for most corporations
investing in it (so they can invest only in "marginal" improvements,
even if "marginal" may mean several person-years to them!).
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} ***
This is subjective!
I am more near to "newbie" state that Richie or you Diego are. So I
probably understand more their particular feelings and not being a
native English speaker also helps a big lot :-)
BTW, GCC development favors small patches, and that is a big bias.
Cheer
On Thu, 23 Jun 2011 18:05:38 +0200
Pierre Vittet wrote:
>
> 2011-06-22 Pierre Vittet
>
> * melt-runtime.c (load_melt_modules_and_do_mode): load extra module
>before setting options
Thanks. Committed revision 175337. [on the MELT branch]
Cheers
--
Basil
include
> headers.
Thanks for the work. Almost perfect!
Your ChangeLog entry is not properly aligned. And what is happenning when
MELT is running in LTO mode?
Cheers.
PS. I will call you.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile:
. */
- fprintf (fp, " %-22s:", tv->name);
+ fprintf (fp, " %-24s:", tv->name);
#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 f
> > #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.
> > ##
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/
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/
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
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
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
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
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
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,
> 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
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
> 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
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
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.
On Thu, 21 Jul 2011 10:03:22 +0200
Romain Geissler wrote:
> Hi,
>
> I added a few includes i need to define some new primitives.
>
> Basile, i included two "c-family/*.h" files, but be aware that currently
> GCC does not install this headers in the c-family direct
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
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
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
(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
***
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
On Fri, 15 Apr 2011 06:38:46 +0300
Laurynas Biveinis wrote:
> 2011/4/11 Basile Starynkevitch :
> >
> > The attached file improves the situation, by flagging input files and
> > generating ggc_alloc macros only relevant to plugin files.
>
> What about include files i
al! I can't see how that hashtable would ever work. Do
> we have any tests for gengtype-state ? Am I missing something ? :-)
>
> Else, Ok to commit the following patch ?
I am not authorized to Ok it, but I hope it will be oked.
Thanks for finding that bug.
Cheers
--
Basile STARYNK
_assert (UNION_OR_STRUCT_P (s));
> OK with these changes and confirmation that the patch was tested.
Committed revision 172705.
Thanks
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg
haps in some permissive mode, or with warnings)
Regards.
PS: By standard C++, I mean some recent or future C++ ISO standard (eg C++1x or
C++0x).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie,
On Fri, 29 Apr 2011 12:32:24 -0700
Mike Stump wrote:
> On Apr 29, 2011, at 11:46 AM, Basile Starynkevitch wrote:
> >
> > This bring me to a question. Does the C++ standard imply that this is
> > never a null pointer?
>
> Does this:
>
> 4 Certain other
ss?
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 Mon, 9 May 2011 19:03:54 +0200
Basile Starynkevitch wrote:
> I applied the patch. The gcc/ChangeLog.MELT proposed by Pierre was
> wrong, I wrote:
>
> 2011-05-09 Pierre Vittet
>
> * melt-runtime.c (melt_garbcoll): Don't force collection by
> gcc_collec
Hello All,
I just merged the trunk rev 173647 into MELT branch 173652:
2011-05-11 Basile Starynkevitch
MELT branch merged with trunk rev 173647 using svnmerge
That was quite a massive merge. The previous time trunk was merged into MELT
branch was
2011-03-14 Basile Starynkevitch
it takes its arg from
> MELTHERE_CLAGS.
Thanks. Committed revision 173796.
--
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} ***
And the colon shouldn't have any space before.
So I applied the patch with the following entry:
2011-05-17 Pierre Vittet
* Makefile.in (melt_module_dir,install-melt-mk): Correct path
errors.
Committed revision 173835.
Thanks.
--
Basile STARYNKEVITCH http://stary
On Wed, May 18, 2011 at 10:27:11AM +0400, Andrey Belevantsev wrote:
> On 17.05.2011 23:42, Basile Starynkevitch wrote:
> >On Tue, 17 May 2011 21:30:44 +0200
> >Pierre Vittet wrote:
>
> >>My contributor number is 634276.
> You don't have to write your FSF contr
nt any debug printing in the usual case when -fmelt-debug is
not given to our cc1) Look at debugloop in xtramelt-ana-base.melt for
an example (notice that debugeprintfnonl is a C macro printing the MELT
source position.
So please resubmit a slightly improved patch.
Regards.
--
Basile STARYNKEVIT
patch quite nice.
However, did you check that the atomic qualifier is correctly written &
re-read in the state (I believe you did, otherwise it probably won't
work). This is needed for plugins using it, or using atomic qualified
fields of existing (or future) structures.
Regards
--
Ba
On Thu, 19 May 2011 21:45:49 +0200
Basile Starynkevitch wrote:
> However, did you check that the atomic qualifier is correctly written &
> re-read in the state (I believe you did, otherwise it probably won't
> work). This is needed for plugins using it, or using atomic qua
7;t understand the
criteria to admit Pierre to the Write After Approval list of
maintainers with a write access to GCC SVN...
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} ***
ion 170736 of the MELT branch.
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} ***
ates the fact that adding some regexp rules to gengtype
was a good idea).
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} ***
04-04 Basile Starynkevitch
* gengtype.c (write_typed_alloc_def): Gets extra outf_p argument
and use it.
(write_typed_struct_alloc_def, write_typed_typedef_alloc_def)
(write_typed_alloc_defns): Likewise.
(main): Calls write_typed_alloc_defns with output_h
\
+ gimple-pretty-print.h tree-pretty-print.h realmpfr.h \
$(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
# generate the 'build fragment' b-header-vars
## gcc/ChangeLog entry
2011-04-07 Basile Starynkevitch
* Makefile.in (PLUGIN_HEADERS): Add gimple-pret
On Thu, 7 Apr 2011 21:41:18 +0200
Basile Starynkevitch wrote:
>
> Hello All,
>
> The following tiny patch add some files to PLUGIN_HEADERS.
> Since they are missing in 4.6, I had to copy them in the MELT plugin
> tar ball release candidate 0.
Sorry, my mailer wrapped the p
On Thu, 7 Apr 2011 05:45:42 +0300
Laurynas Biveinis wrote:
> The patch is correct in general.
You didn't say "Ok with changes", so attached here is the patch to trunk 172161
gcc/ChangeLog entry ##
2011-04-08 Basile Starynkevitch
On Fri, 8 Apr 2011 15:29:48 +0300
Laurynas Biveinis wrote:
> > 2011-04-08 Basile Starynkevitch
> > * gengtype.c (write_typed_alloc_def): New argument f. Use it instead
> > of header_file.
> > (write_typed_struct_alloc_def, write
would just be a matter of adding GTY annotations
somewhere.
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} ***
On Sun, 10 Apr 2011 21:47:05 +0300
Laurynas Biveinis wrote:
> 2011/4/8 Basile Starynkevitch :
> > Actually, the above committed patch is better than nothing, but not
> > perfect. It happens to generate ggc_alloc macros for things which are
> > not defined in the plugin (h
On Fri, 8 Apr 2011 19:55:51 +0200
Basile Starynkevitch wrote:
> Committed revision 172203 (on trunk).
>
> Actually, the above committed patch is better than nothing, but not
> perfect. It happens to generate ggc_alloc macros for things which are
> not defined in the plugin (howev
On Thu, 7 Apr 2011 21:43:44 +0200
Basile Starynkevitch wrote:
> > The following tiny patch add some files to PLUGIN_HEADERS.
## gcc/ChangeLog entry
2011-04-11 Basile Starynkevitch
* Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print.h
tree-pretty-print.h &
On Mon, 11 Apr 2011 15:27:15 -0400
Diego Novillo wrote:
> On Mon, Apr 11, 2011 at 15:24, Basile Starynkevitch
> wrote:
>
> > 2011-04-11 Basile Starynkevitch
> > * Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print.h
> > tree-pretty-print.h &
};
+ int get_column() const {
+return m_column;
+ };
+ bool is_created_by_user() const {
+return m_created_by_user;
+ };
};
class type : public memento
Could someone please review it (and if autorized to) apply it? I feel it is
pretty trivial and definitely useful.
Thanks
101 - 160 of 160 matches
Mail list logo
