>
>> Even then, the ppl configury isn't detecting the gmp we just built. It
>> seems as though we should install gmp in a local temporary install tree
>> and point ppl at that. See below for a trace of the ppl configury as it
>> attempts to detect an in-tree gmp (after applying the patch above)
On Mon, May 4, 2009 at 01:42, Jerry DeLisle wrote:
> I just completed a sync to trunk that I have not committed back yet and I
> get the following error during bootstrap on the local branch.
>
> libbackend.a(plugin.o): In function `plugin_default_version_check':
> /home/jerry/gcc/objdev/gcc/../../
Oliver Kellogg wrote:
> Further question, what is the process for integrating my changes
> into the GCC trunk?
The generic procedure is documented at the gcc web site:
http://gcc.gnu.org/contribute.html
http://gcc.gnu.org/svnwrite.html
> I would assume that I need to
> 1) Make
On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini wrote:
> Hi all, I plan to merge the cond-optab branch next Friday morning
> European time. No commit should be made to trunk from Friday 6:00 AM
> GMT to 12:00 AM GMT (or probably earlier).
While I think the slush is practially over (I am not aware
On Mon, May 4, 2009 at 7:14 AM, Richard Guenther
wrote:
> On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini wrote:
>> Hi all, I plan to merge the cond-optab branch next Friday morning
>> European time. No commit should be made to trunk from Friday 6:00 AM
>> GMT to 12:00 AM GMT (or probably earlier)
Richard Guenther wrote:
> On Mon, May 4, 2009 at 3:36 PM, Paolo Bonzini wrote:
>> Hi all, I plan to merge the cond-optab branch next Friday morning
>> European time. No commit should be made to trunk from Friday 6:00 AM
>> GMT to 12:00 AM GMT (or probably earlier).
>
> While I think the slush is
Hi all, I plan to merge the cond-optab branch next Friday morning
European time. No commit should be made to trunk from Friday 6:00 AM
GMT to 12:00 AM GMT (or probably earlier).
Thanks!
Paolo
Michael Hope wrote:
(define_expand "reload_outsi"
[(parallel [(match_operand 0 "memory_operand" "=m")
Perhaps the problem is that the output operand is an unallocated
pseudo-reg instead of a MEM. Looking at other targets that have
reload_out* patterns, I see that they have predicates that
2009/5/4 Peter Dimov:
> Jonathan Wakely:
>>
>> 2009/5/4 Joseph S. Myers:
>> > On Mon, 4 May 2009, Jan Hubicka wrote:
>> >
>> >> On mainline I enabled infinite loop removal at
>> >> -funsafe-loop-optimizations. I would suggest adding
>> >> -fempty-loops-terminate and make it default for C++? It does
Paolo Bonzini wrote:
>>> Even then, the ppl configury isn't detecting the gmp we just built. It
>>> seems as though we should install gmp in a local temporary install tree
>>> and point ppl at that. See below for a trace of the ppl configury as it
>>> attempts to detect an in-tree gmp (after appl
> Ian, thanks for reporting this. I'll investigate this more. It
> affects only ports using priority allocation (I know only one which
> is m32c). DJ just recently reported a reload failure problem on
> m32c. Probably that is because of this wrong code.
In checking through this code, I see th
Sorry for dragging this discussion out from the distant past. I'm in
the process of porting some plug-ins from the old plugin SVN branch to
the new plug-in system, and this is one of the issues blocking me. My
plug-ins maintain some tree nodes that I want to stay alive from
function to function.
Hi, I am going to create a gcc branch for the functionality of
lightweight IPO. The description of the project and current status can
be found in http://gcc.gnu.org/wiki/LightweightIpo. Some highlights:
1) If you already use FDO in your build, you also get IPO almost for free;
2) It is an IPO sol
Justin Seyster wrote:
We just have to add some small code [2] into the ggc_mark_roots routine of
gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h. This is
not a big deal. We should simply add a routine
ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its
ar
Presently, the -combine option works only for C sources. I was wondering
whether there are technical reasons for not supporting it for C++ sources. If
not, are there plans for providing this support in the near future?
Pramod
_
In
>> No, it was not. So you can drop in gmp/mpfr, or ppl/cloog, but not all
>> four.
>
> I would like to again suggest that we declare in-tree builds of this
> stuff out of scope.
For ppl/cloog which are not mandatory I agree. I think in-tree
GMP/MPFR however is especially useful for people who bu
16 matches
Mail list logo
