Re: MELT help: how to autoconf-igure makefile fragments?

Joern Rennecke wrote: Quoting Basile STARYNKEVITCH : But I don't understand much about gcc/configure.ac and I am extremely scared to touch that file. A very big thanks for answering. There is an info page for autoconf. If you don't like (to learn how to use) info, you can simpl

plugin issues to fix (or document) before 4.5 release

ELT plugin do encounter them, and have naughty tricks to avoid (ie circumvent) them. It would be much better if it didn't had to avoid these issues. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de

GCC server is down?

Hello All, It seems to me that now (GMT time is Sun Dec 13 16:14:59 UTC 2009) the gcc.gnu.org server is down (unreachable, don't ping, don't answer HTTP requests). This seems to be the case for a couple of hours at least. Regards -- Basile STARYNKEVITCH http://starynk

Re: C parser modification & questions

evolution (which is always a big lot of work, even within plugins). Regards. PS. For people interested, I am also begin to add an alternative infix syntax to MELT. This only for people allergical to lot of insipid stupid parenthesis syntax. -- Basile STARYNKEVITCH http://s

Re: How to make make changes in gcc code

r a higher-level language to code plugins. Still, we cannot help you because we cannot guess your objectives. 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

Re: fixincludes

ems (like proprietary Unixes eg SunOS or HPUX or AIX), but I cannot understand its use on GNU systems. Or perhaps I completely misunderstood the role of fixinclude. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8,

trunk's genmodes crashes on Ubuntu/Lucid (alpha2 snapshot) not on Debian/Sid [both AMD64 architecture]

o reproduce that bug on my desktop running Debian/Sid. Both are AMD64 architectures. Does anyone observed that also? It seems Ubuntu/Lucid specific ... (kernel is 2.6.32-12-generic from ubuntu if that matters; libc6 package is 2.11.1-0ubuntu2 from ubuntu). Regards. -- Basile STARYNKEVITCH

Re: trunk's genmodes crashes on Ubuntu/Lucid (alpha2 snapshot) not on Debian/Sid [both AMD64 architecture]

Basile STARYNKEVITCH wrote: Hello When building the gcc trunk revision 156557 on Ubuntu lucid AMD64 (the alpha of the next Ubuntu release, which I upgraded just today on Febr 06, 2010), I am getting a repeatable SIGSEGV from genmodes This is very probably an strcmp bug inside Ubuntu/Lucid

ping - plugin directory

e its chances of being reviewed? 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: GCC freezing for a Multiply Chain

passes in plugins, and it used to generate huge initialization routines. This is no more the case since a few weeks (because there is no more huge routines, only several big ones), MELT can be reasonably compiled on a desktop even with optimization like -O2. -- Basile STARYNKEVITCH http

student internship & GCC

, intern, in France? Regards. PS. It may happen that the internship won't happen (for various reasons). I just want to settle such issues quickly as possible. I don't have the energy & incentive to get another assigment of copyright from CEA for him. -- Basile STARYNKEVITCH

clearing many bytes variables (could use one machine instruction)?

is the Core2 processor sufficient smart to execute exactly as fast a sequence of 8 consecutive byte moves as a single 8-byte word move? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bou

Re: clearing many bytes variables (could use one machine instruction)?

On Tue, Mar 09, 2010 at 05:25:35PM +0600, Alexey Salmin wrote: > On Tue, Mar 9, 2010 at 3:58 PM, Basile Starynkevitch > wrote: > > Hello All, > > > > With a recently compiled gcc-trunk on x86-64/linux, I am compiling the > > folllowing example: > > &

Re: clearing many bytes variables (could use one machine instruction)?

having a structure has probably also some shortcommings: I would guess that it is much harder for GCC to keep my flags in registers only. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340

Does gengtyped gt-*.h depends upon the configuration of the compiler?

ce & the build trees of the GCC for which the plugin is built is quite unnatural (but of course I understand why it is needed) and could be perhaps incompatible with the way many Linux distributions (including Debian) are naturally packaging GCC. Comments are welcome. Regards. -- Ba

Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?

Basile Starynkevitch wrote: In other words, would a gt-melt-runtime.h generated on Debian/Linux/AMD64 would be ok for a Debian/Linux/x86 or Debian/Linux/ARM? I blindly guess that probably not, but I am not sure. Apparently, the constraint that gengtype requires availability of both the

Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?

124.html message) could be of interest to debian-...@lists.debian.org I am also BCC-ing it to them. 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: Does gengtyped gt-*.h depends upon the configuration of the compiler?

mp; gengtype improvements (w.r.t plugins) in your gc-improv branch? 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} ***

status of GCC 4.5 w.r.t. plugins?

s at Solutions Linux next week in Paris. Also, MELT has now a script to build it as a plugin, but the gengtype requirement that the GCC source & build tree [of the GCC compiler into which MELT is plugged in] should be available is a significant annoyance, in particular to Debian GCC packag

packaging GCC plugins using gengtype (e.g. MELT)?

Basile Starynkevitch wrote in http://lists.debian.org/debian-gcc/2010/03/msg00047.html Now, one of the issues about MELT & Debian packaging is the fact that melt-runtime.c (the source of melt.so plugin) uses GTY http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Informa

Re: packaging GCC plugins using gengtype (e.g. MELT)?

Matthias Klose wrote: [posted on both gcc@ & debian-gcc@ lists] On 14.03.2010 13:15, Basile Starynkevitch wrote: See also http://gcc.gnu.org/ml/gcc/2010-03/msg00129.html & http://gcc.gnu.org/ml/gcc/2010-03/msg00132.html - for those new to MELT see http://gcc.gnu.

Re: Hash Function for "switch statement"

lem of a huge size of jump table as well. It is much more complex than that. Read the paper "A Superoptimizer Analysis of Multiway Branch Code Generation" by Roger A. Sayle in GCC summit 2008 proceedings. www.gccsummit.org/2008/gcc-2008-proceedings.pdf Regards. -- Basile STARYNKEVI

Re: GCC 4.5 Status Report (2010-03-15)

://gcc.gnu.org/ml/gcc/2010-03/msg00140.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 *** opinions {are only mines, sont seulement les miennes} ***

Re: Hash Function for "switch statement"

MPLE representation into another, and MELT is well suited for that. Feel free to ask more. 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 m

Re: [rfc] common location for plugins

post of the patch is http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00644.html Given Matthias wish, I dare ping again that patch Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg

Adding statement to an already defined function in GCC

t Tree/Generic & Gimple in http://gcc.gnu.org/onlinedocs/gccint/ Good luck. If you want to use MELT, feel free to ask me (e.g. on this list). 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} ***

accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

right transfer, if his is accepted as intern. His internship at CEA might start on first of june 2010 till 31 of august 2010. Sorry for bothering the list, but I don't understand all the details. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkev

Re: accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

Joseph S. Myers wrote: On Tue, 30 Mar 2010, Basile Starynkevitch wrote: 1. how to admit as soon as possible (as a a write-after-approval maintainer) a student who did get a signed copyright disclaimer from his university to get a SVN+ssh write account to GCC In addition to the paperwork

List for discussion in French on GCC MELT = gcc-melt-fre...@googlegroups.com

gcc-melt-fre...@googlegroups.com but messages there should be in French. Les messages sur gcc-melt-fre...@googlegroups.com doivent être en français Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie,

Re: WHOPR bootstrap, when/how?

ps all global names as global symbols from the linking point of view). So what are the real use cases of -combine not covered by -flto ? Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340

Re: dragonegg in FSF gcc?

ards -- 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: dragonegg in FSF gcc?

Duncan Sands wrote: In my opinion a bit of friendly competition from LLVM is on the whole a good thing for gcc. I definitely agree with that position. Real competition between LLVM & GCC is good for both projects, and is good for free software as a whole. Cheers. -- Ba

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

tain plugin code). Perhaps most of the GCC community don't care about getting more academics contribute to GCC (in my opinion this is a mistake of the GCC community; we should attract more academics). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: bas

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

Ian Lance Taylor wrote: Basile Starynkevitch writes: My point is that academics can quite easily contribute to GPL software, but much harder obtain the necessary legal authorizations to transfer copyright to FSF. My intuition is that if (in a different past & a different world which did

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On Thu, Apr 15, 2010 at 10:26:16AM +0200, Manuel López-Ibáñez wrote: > On 14 April 2010 23:34, Basile Starynkevitch wrote: > > > > And my personal preference on GCC licensing would be more a Linux-kernel > > like GPL with copyright belonging to authors employee (I don't

Re: GCC 4.5.0 Released

Mark Mitchell wrote: The Free Software Foundation and the GNU Compiler Collection (GCC) development team have released GCC 4.5.0. [...] It is really unfortunate the annoucement did not mention plugins, another major feature of GCC. Why ? -- Basile STARYNKEVITCH http

Re: GCC 4.5.0 Released

On Mon, Apr 19, 2010 at 10:50:48AM +0200, Richard Guenther wrote: > On Mon, Apr 19, 2010 at 7:04 AM, Basile Starynkevitch > wrote: > > Mark Mitchell wrote: > >> > >> The Free Software Foundation and the GNU Compiler Collection (GCC) > >> d

Re: Plan for gc-improv merge

maintainers. 6) GTY documentation update in GCC internals manual. Yes, these are important, especially since the plugin interface expose a bit more of ggc.h ... Thanks for the good work! Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mob

Re: GCC 4.5.0 Released

Mark Mitchell wrote: Basile Starynkevitch wrote: It is really unfortunate the annoucement did not mention plugins, another major feature of GCC. Why ? I consider plug-ins an important feature for the future of GCC. I gave a talk this past week as the Linux Foundation Collaboration Summit in

Re: Code assistance with GCC

thinking that he might instead write a plugin which works at the Generic/TREE (or even perhaps Gimple) level. What do other people think? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340

Re: Code assistance with GCC

Daniel Jacobowitz wrote: On Wed, Apr 21, 2010 at 01:12:37PM +0200, Basile Starynkevitch wrote: However, I am not sure to understand why Tomohiro needs to hack the GCC parser itself. I was thinking that he might instead write a plugin which works at the Generic/TREE (or even perhaps Gimple

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

to generate warmelt*1.c, compile them to warmelt*1.so, and use them to generate warmelt*2.c). This MELT bootstrap is routinely done with GCC 4.4 & GCC 4.5 (the warmelt*1.c is generated but does not work ok). Regards. PS. About GCC MELT see http://gcc.gnu.org/wiki/MiddleEndLispTranslator

Re: --enable-plugin as default?

sides, my feeling is that most Linux distributions will (or are already) package GCC 4.5 with plugins enabled. Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, F

Re: Why not contribute? (to GCC)

weaknesses of GCC. My feeling is that the legalese inside GCC have been defined in a different time and world than today! Any even since I did send patches to GCC since several years, I am still scared even now when sending one. Sorry for spaming the list with such non-technical blabla. C

Re: Why not contribute? (to GCC)

Manuel López-Ibáñez wrote: On 23 April 2010 23:19, Basile Starynkevitch wrote: I do know that the legal system of GCC is nearly impossible to change (we all remember how getting the runtime license of GCC compatible with plugins took so long) but I believe it is one of the weaknesses of GCC

Re: Why not contribute? (to GCC)

Maybe U.Illinois don't use words like "unlumited liaibility". But we cannot know for sure, these documents are not public. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie,

Re: Why not contribute? (to GCC)

the issues surrounding patents in the default disclaimer language (though I understand that the FSF has negotiated other language with a number of corporate contributors). Yes yes yes! Thanks for the clarification! -- Basile STARYNKEVITCH http://starynkevitch.net/Bas

Re: Why not contribute? (to GCC)

Joe Buck wrote: On Fri, Apr 23, 2010 at 05:05:47PM -0700, Basile Starynkevitch wrote: The real issue is not the copyright disclaimer, it is the legal terms inside. Maybe U.Illinois don't use words like "unlumited liaibility". Where are you getting this term "unlimited liab

Re: Why not contribute? (to GCC)

o win, it is not such a big deal. Free software (as an ideal, and as a practice) is more important than individual lines of code. What is important is the existence of good free compilers, and having fun to hack inside them. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/B

Re: Defining a common plugin machinery

[since it is dlopen-ed] without being FSF copyrighted, but perhaps the goal of the steering committee is to avoid that. And I even don't understand who is deciding what on the plugin issues & the runtime license issue. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net

Re: Defining a common plugin machinery

me license. I think that most of the issues are not technical here, but legal (the future runtime license) and social (get some plugin code accepted in the 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 mines, sont seulement les miennes} ***

Re: Defining a common plugin machinery

l at first be something which can be disabled at configure time, and will be disabled by default. My main concern is plugins & passes. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340

Re: Defining a common plugin machinery

derstand what would make them more acceptable. In both cases, plugins have probably some requirements defined by the future runtime license, which I don't know yet. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2

Re: Defining a common plugin machinery

Hello All, Robert Dewar wrote: Gerald Pfeifer wrote: On Wed, 1 Oct 2008, Basile STARYNKEVITCH wrote: is the goal to only permit FSF copyrighted GPLed plugins The FSF is concerned about making and keeping software free. Copyright assignment to the FSF is required to get code into the FSF

Re: Defining a common plugin machinery

hat for perfomance reasons it is not supposed to be extensible (so there is no way to add additional data into LTO). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France

adding ability to scan few local variables in GGC?

help 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 mines, sont seulement les miennes} ***

Re: adding ability to scan few local variables in GGC?

Hello All, Andrew Pinski wrote: On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: Hello All, I am sometimes wishing to be able to scan some few local variables in GCC garbage collector, GGC. The only time I can think of when you want to do that is wh

Re: adding ability to scan few local variables in GGC?

Richard Guenther wrote: On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: Hello All, Andrew Pinski wrote: On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: Hello All, I am sometimes wishing to be able to scan so

Re: adding ability to scan few local variables in GGC?

Basile STARYNKEVITCH wrote: I'm not sure to understand the meaning of "MELT GC being incompatible with GGC one". On the contrary, it is designed to be compatible, it is compatble in practice, and it works quite well. If an ggc_collect_with_local scheme is not possible (but

GCC & OpenCL ?

the GPU). Is there any branch or experimental code for adding OpenCL into GCC? I suppose that some people are already working on that, but I didn't find easily precise references. Any clues, insights, contacts on these items? Regards. -- Basile STARYNKEVITCH http://starynkevitc

Re: GCC & OpenCL ?

pected to make proprietary extensions legally impossible, or at least difficult). 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 seuleme

Re: [plugins] Branch for plugins development created

gainst Diego effort, just a possible mine misunderstanding ! I was thinking that patching the trunk for plugins would be the easiest way. Thanks to all (and sorry for my bad english). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33

Re: [plugins] Comparison of plugin mechanisms

plugin APIs I believe that MELT probably don't need an extra column, and that for the purpose, impact, implementation,aspects it fit into the first column "production plugins" while for most other aspects MELT fits into the second column. Regards. PS. In all this email, d

[plugins] two confusing plugin related branches

letter (the last s of plugins). Given that the svn://gcc.gnu.org/svn/gcc/branches/plugin branch is not really active, I suggest to svn mv svn://gcc.gnu.org/svn/gcc/branches/plugin svn://gcc.gnu.org/svn/gcc/branches/old-plugin What do you think about that? Regards. -- Basile STARYNKEVITCH

correct way of having a function pointer inside a GTY()-ed struct?

GTY-ed struct. So I believe my concern is potentially not only inside 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 mines, sont seulement les miennes} ***

Re: correct way of having a function pointer inside a GTY()-ed struct?

Steven Bosscher wrote: On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH wrote: But last time I tried (more than a year ago) that didn't work because gengtype is unhappy with GTY((skip))-ed fields of a type it does not understand. Why do you have to put that data structure

Re: correct way of having a function pointer inside a GTY()-ed struct?

Hello All, Richard Guenther wrote: On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH wrote: Hello All, What is the politically correct way of having an ignored function pointer inside a GTY-ed struct? To be more precise, I have typedef basilys_ptr_t basilysroutfun_t

Re: correct way of having a function pointer inside a GTY()-ed struct?

)) routfunad; basilys_ptr_t routdata; unsigned nbval; basilys_ptr_t GTY ((length ("%h.nbval"))) tabval[FLEXIBLE_DIM]; }; and it works committed MELT branch rev144987 Apologies for the noise! Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Bas

Re: correct way of having a function pointer inside a GTY()-ed struct?

Joern Rennecke wrote: Basile STARYNKEVITCH: > So my point is that I want to put inside the GTY-ed struct basilysroutine_st > an ignored (I mean GTY((skip))-ed) field called routaddr which is a function > pointer > (function of type basilysroutfun_t - which is typedef-ed above). &

status of the plugins branch vs 4.4?

n the trunk. -- 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: GCC + libJIT instead of LLVM

nery comes into the trunk, nothing prevent Kiril or others to experiment a plugin which uses libjit internally. And you (Kiril or others) could even start a branch right now (provided you did comply with the legal requirements of http://gcc.gnu.org/contribute.html ie the FSF copyright transfe

Re: GCC + libJIT instead of LLVM

ress ourself fluently in English. If it is the case please forgive us (or just try to interact on a french or russian mailing list!). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bo

Plugins & GGC ie GTY

ould require a short patch to ggc-common.c or similar ggc-*.c files. Did I miss anything? Regards. PS. This is not an April Fool joke! I am quit serious about extra GTY-ed roots. It is for me an essential & required condition to perhaps transform the MELT branch into a mega-plugin.

Re: Plugins & GGC ie GTY

alloc or xcalloc, or should never call warning_at, or should never call XXX! Why? So what are plugins for? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, F

Re: Plugins & GGC ie GTY

Basile STARYNKEVITCH wrote: Richard Guenther wrote: Plugins shouldn't keep permanent references to GCed memory. At least that would make it unnecessary to do what you suggest. I strongly disagree with that, and I simply do not understand your position. In my perception, plugin

Re: Plugins & GGC ie GTY

care yet about PCH & plugins, which is a difficult subject by itself (even without any GTY inside plugins). Comments (especially constructive comments) are welcome Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359

Re: GCC + libJIT instead of LLVM

GCC is the good vehicule for that. A lot of stuff inside GCC is really designed for AOT! Of course, I don't understand all the details involved. I don't know much about the various branches I mention in this email. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Ba

Re: Checking for the Programming Language inside GCC

information, that would be better settled in the long term thru an evolution or enhancement of the middle end representations... Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La

Re: Plugins & GGC ie GTY

not the garbage collector I'm dreaming (mostly because it does not handle local roots), burt barely enough for me. I am aware that my position is in the minority. Note [2]: See the http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02233.html thread -- Basile STARYNKEVITCH

MELT tutorial on the wiki

Hello All I added a (still incomplete) MELT tutorial on the wiki: http://gcc.gnu.org/wiki/MELT%20tutorial It tells you how to do a hello world in MELT. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la

plugins callbacks and data

*plugin_name, enum plugin_event event,, void* user_data); ? What do you think? BTW, tjhe current gcc/doc/plugins.texi don't mention PLUGIN_INFO, unless I am mistaken. And the enum plugin_event there is not the same as in gcc-plugins.h Regards. -- B

Re: Adding new runtime library

arguments needed). The hardest part is indeed to write an optimisation pass :-) 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

plugins & howto & generators

-event. I am considering enhancing the gengtype tool so that gengtype --plugin yourplugin.c gt-yourplugin.h would generate the gt-yourplugin.h neede in yourplugin.c Comments are welcome. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobi

"plugin"-ifying the MELT branch.

27;t be able to attend the summit this year. Regards. Note *: MELT is a meta plugin in the sense that it generate C code, compile it, and dynamically load it. However, the MELT generated plugins do not follow the plugin API; they have their own ones! -- Basile STARYNKEVITCH http://st

several installed gcc, or libdir should depend upon -program-suffix...

? How do you folks have several GCC installed at the same prefix? Regards. PS: I hope all gcc summit attendees have a nice summit. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine

increasing the number of GCC reviewers

today? 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: increasing the number of GCC reviewers

Andrew Haley wrote: Basile STARYNKEVITCH wrote: Perhaps could be discussed at the summit some way to increase the set of reviewers, i.e. the set of people able to say Ok to a patch submitted on gcc-patches@ As I understand it, the set of reviewers allowed to say OK to a patch is limited

Re: increasing the number of GCC reviewers

Basile STARYNKEVITCH wrote: Andrew Haley wrote: Basile STARYNKEVITCH wrote: PS. [note *] GCC is a huge software, so understanding well a part of it could be enough to understand some patches. And GCC is a huge software I meant GCC is growing a lot. Its increase rate (about 1MLOC in less

Re: increasing the number of GCC reviewers

increased by 30% in 3 years, as did the source code! Note 2: I have no idea if the patch-to-be-reviewed queue of each reviewer has increased since 2 years ago! I intuitively feel it did increase a lot, i.e. reviewers have much more pressure on them. Maybe I am wrong! -- Basile STARYNKEVITCH

Re: increasing the number of GCC reviewers

Andrew Haley wrote: Basile STARYNKEVITCH wrote: FWIW, I am not taking this question personally (I don't really claim that I could become any kind of reviewer; I believe in general that reviewing abilities should be evaluated by others.). I just think the set of reviewers should signific

Re: plugin callbacks after compiler errors

I tend to believe it should not become a general policy (but at least tunable plugin by plugin) but I may be wrong. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France

Re: plugin callbacks after compiler errors

#x27;t care if russian speakers call me Vassilii or even Vassia. 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} ***

instructions for compiling plugins?

umentation http://gcc.gnu.org/onlinedocs/gccint/Plugins.html ? By the way, are we sure that install-plugin target in gcc/Makefile is invoked from a toplevel sudo make install in the build dir? I feel it might not be the case, but I am not sure.. Regards. -- Basile STARYNKEVITCH http://starynkev

Re: "plugin"-ifying the MELT branch.

Basile STARYNKEVITCH wrote: Can a branch be simply a plugin, or should I close (soon) the melt-branch and start a melt-plugin-branch on the SVN. If I do that, do I need some authorization? from whom? Apparently, nothing very special is required to start a new branch. So I intend to

Re: "plugin"-ifying the MELT branch.

Richard Guenther wrote: On Tue, Jun 16, 2009 at 1:13 PM, Basile STARYNKEVITCH wrote: Basile STARYNKEVITCH wrote: Can a branch be simply a plugin, or should I close (soon) the melt-branch and start a melt-plugin-branch on the SVN. If I do that, do I need some authorization? from whom

Re: "plugin"-ifying the MELT branch.

I (Basile) very probably misunderstood what Joseph Myers or Richard Guenther meant. What I might have [mis]understood scares me. This is a request for clarification. Joseph S. Myers wrote: On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote: I thought on the contrary that is was

Re: instructions for compiling plugins?

edocs/gccint/Plugins.html and not in http://gcc.gnu.org/wiki/plugins I did submit a documentation patch. See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01169.html (yes, my English language is poor. I would expect some improvements). regards. -- Basile STARYNKEVITCH

Re: "plugin"-ifying the MELT branch.

not pluginified yet. So it will stay some time as a branch, because today it cannot be a plugin (for various small technical details). -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La

Re: "plugin"-ifying the MELT branch.

Richard Guenther wrote: On Tue, Jun 16, 2009 at 7:30 PM, Basile STARYNKEVITCH wrote: Diego Novillo wrote: On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote: Basile, people are saying that MELT no longer belongs in a branch of the GCC repository because now that plug-ins are

gengtype & plugins.

riately a $gccplugins/gtyp-input-plugins.list B. we should install gengtype as gcc-gengtype at some appropriate place C. we should document that, and update the documentation on how to build plugins. I don't know what mailing list is the better place to discuss that. Regards. -- Basile

<    1   2   3   4   5   6   7   8   9   >