On Fri, Feb 6, 2009 at 2:49 PM, Diego Novillo wrote:
> Before I can accept patches, however, I need to make sure that
> everyone has copyright assignments on file. I know that Taras, Basile
> and Le-Chun do. Sean and Grigori, do you folks have copyright papers
> already?
Grigori works for INRIA
Our SVN tree is here:
svn co svn://gcc.gnu.org/svn/gcc/branches/plugin gcc
This is an old branch off the GCC 4.3 mainline that Eric Christopher
helped create after the 2007 GCC Summit, but we can update it if
necessary. It includes libtool and libltdl, which may be useful.
FWIW, the libto
On Fri, Feb 6, 2009 at 18:15, Gerald Pfeifer wrote:
> You don't need approval for this, but if you did, I'd be happy to
> approve this specific patch. ;-)
OK, thanks.
> (You may want to consider a note on who is the main maintainer of the
> branch, and a convention on subject line tags, such as
On Fri, 6 Feb 2009, Diego Novillo wrote:
> I have created the plugins branch (rev. 143989). As I offered before,
> I will help maintain the branch synchronized with mainline and with
> patch reviews. The branch can be checked out with
>
> $ svn co svn://gcc.gnu.org/svn/gcc/branches/plugins
Nice
Snapshot gcc-4.4-20090206 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Feb 6, 2009 at 7:32 PM, Adam Nemet wrote:
> I think you really need the Joern's optmize_related_values patch. Also see
> PR33699.
I wouldn't recommend that patch, but yes: Something that performs that
optimization ;-)
Gr.
Steven
This is a strange result, I seem to have everything I wanted, fortran and
ada etc but no actual gcc file.
If I look at the final output in the $DEST/bin ddir I see this, sorted by
inodes numbers with blank lines added for clarity :
# ls -lapin bin | sort -n | sed 's/^[ \t]*//'
otal 92092
117274
On Fri, Feb 6, 2009 at 16:04, Basile STARYNKEVITCH
wrote:
> But given that most people agree that (since the plugin idea is not too
> ambitious) the plugin effort is not a big one (e.g. much much smaller than
> your heroic old-gimple => tuple work) why did'nt you consider accepting
> plugin relat
Diego Novillo wrote:
I have created the plugins branch (rev. 143989). As I offered before,
I will help maintain the branch synchronized with mainline and with
patch reviews. The branch can be checked out with
$ svn co svn://gcc.gnu.org/svn/gcc/branches/plugins
Thanks for the effort Diego.
B
I have created the plugins branch (rev. 143989). As I offered before,
I will help maintain the branch synchronized with mainline and with
patch reviews. The branch can be checked out with
$ svn co svn://gcc.gnu.org/svn/gcc/branches/plugins
As usual, I created a wiki page for the branch
(http://
Sean,
I don't really think most people are contributing to GCC for the
bragging rights (at least I am not :-)). I would consider this a
concerted, collaborating effort to get a simple, robust, and
accommodating plugin design and implementation out as quickly as
possible so that people can start us
On Fri, 2009-02-06 at 12:32 +, Joseph S. Myers wrote:
> On Fri, 6 Feb 2009, Sean Callanan wrote:
>
> > - Modify the GCC link process to use libltdl and libtool -export-dynamic
>
> Although this may make theoretical sense in terms of the work for a
> cross-platform implementation already bein
Bernd Schmidt writes:
> Take a look at reload_cse_move2add.
I don't think that powerful enough; it requires the same destination
registers:
/* Try to transform (set (REGX) (CONST_INT A))
...
(set (REGX) (CONST_INT
Bernd Schmidt writes:
>> But I don't know that gcc will implement the particular optimization
>> that you are looking for. I'm not aware of any other processor which is
>> able to load a large constant in a single instruction, but for which an
>> add instruction is cheaper if there is a similar
Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> All of these have an outer code of SET. Therefore, I'm not quite
>> positive of how I'm supposed to implement my rtx_cost function. Since
>> I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
>> 5), how can I tell the
Jean Christophe Beyler writes:
> All of these have an outer code of SET. Therefore, I'm not quite
> positive of how I'm supposed to implement my rtx_cost function. Since
> I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
> 5), how can I tell the compiler the different costs?
On Fri, Feb 06, 2009 at 11:46:58AM -0500, Jean Christophe Beyler wrote:
> I finally get this :
>
> (const_int 51966 [0xcafe])
> (const_int 51966 [0xcafe])
> (const_int 51971 [0xcb03])
> (const_int 51971 [0xcb03])
>
> All of these have an outer code of SET. Therefore, I'm not quite
> positive of h
On Fri, Feb 6, 2009 at 8:30 AM, Paolo Bonzini wrote:
> Disadvantages: the milestone field is not visible in search lists (maybe
> this can be changed)?
This issue of the search list has come up so many times. You can
change the search list display with different fields. I usually add
"last modi
On Fri, Feb 6, 2009 at 11:30 AM, Paolo Bonzini wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wron
Dear all,
I've been trying to play with the RTX costs by using a target function
using the macro TARGET_RTX_COSTS. However, I haven't been able to
really make any good progress. This is the program I have:
#include
#include
int main(void)
{
long a = 0xcafe;
printf("Final: %lx %lx\n", a
The current system for managing bugzilla priorities has a major problem,
in that it does not identify bugs that reasonably cannot be fixed before
the release.
The current set of priorities is in practice like this:
- P1: most wrong code bugs, and other absolutely blocking problems
- P2: problems
On Fri, 6 Feb 2009, Sean Callanan wrote:
> - Modify the GCC link process to use libltdl and libtool -export-dynamic
Although this may make theoretical sense in terms of the work for a
cross-platform implementation already being done, I doubt it's a good idea
in practice if you want plugin-enabl
As a matter of protocol, I know there are several groups that all have
implementations. I bet any one of them would love to have the credit
of having their implementation be the one that got adopted. (I know
ours would! We're academics and would love to claim bragging rights.)
In practic
I have updated the API Wiki at http://gcc.gnu.org/wiki/GCC_PluginAPI.
1) The way to pass arguments to plug-ins has been reverted to the
approach suggested by many:
--
-fplugin=/path/to/NAME.so -fNAME-arg1=value -fNAME-arg2=value
--
2) The name of struct plugin_registration is now struct
c
24 matches
Mail list logo
