On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni
wrote:
> On Wed, Jul 30, 2014 at 11:49 PM, Prathamesh Kulkarni
> wrote:
>> On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener
>> wrote:
>>> On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener
>>> wrote:
On Wed, Jul 30, 2014 at 12:49 PM, Pratham
On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener
wrote:
> On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni
> wrote:
>> On Wed, Jul 30, 2014 at 11:49 PM, Prathamesh Kulkarni
>> wrote:
>>> On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener
>>> wrote:
On Wed, Jul 30, 2014 at 1:11 PM, Richard
On Thu, Jul 31, 2014 at 11:09 AM, Prathamesh Kulkarni
wrote:
> On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener
> wrote:
>> On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni
>> wrote:
>>> On Wed, Jul 30, 2014 at 11:49 PM, Prathamesh Kulkarni
>>> wrote:
On Wed, Jul 30, 2014 at 4:49 PM, Ri
On Thu, Jul 31, 2014 at 2:44 PM, Richard Biener
wrote:
> On Thu, Jul 31, 2014 at 11:09 AM, Prathamesh Kulkarni
> wrote:
>> On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener
>> wrote:
>>> On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni
>>> wrote:
On Wed, Jul 30, 2014 at 11:49 PM, Pratham
Hi,
I want to find the most consuming compiler process, the time report is as
following:
usr sys wall
TOTAL 759.59 92.92 1396.19
phase generate 498.34 31.1 870.94
template instantiation 90.49 13.9469.89
phase pars
On 07/31/2014 11:25 AM, Gengyulei (Gengyl) wrote:
> How to explain it?
We can't. You haven't told us what is being parsed or even which
language it's written in. Note that GCC's parsing pass isn't simply
a parse: it has to build trees, which can be an expensive process.
Andrew.
Thank you for your answer. I compiled the android source codes.
-邮件原件-
发件人: Andrew Haley [mailto:a...@redhat.com]
发送时间: 2014年7月31日 18:54
收件人: Gengyulei (Gengyl); gcc@gcc.gnu.org
主题: Re: About the most time consuming compiler process
On 07/31/2014 11:25 AM, Gengyulei (Gengyl) wrote:
> How
On Wed, Jul 30, 2014 at 8:00 PM, Jonathan Wakely wrote:
> On 30 July 2014 23:18, Eric Botcazou wrote:
>>> What are you objecting to, calling the next release from trunk 5.0,
>>> and the next one after that 6.0? Or the wording chosen to describe the
>>> new versioning scheme?
>>
>> Let's not start
Tobias, could you please advise me how is it better to determine a
depth for loop (it is necessary for loop_is_parallel_p)? In
graphite-clast-to-gimple.c. it is done by using the number of
dimensions of a domain, which is attached to clast_for. As far as I
know, isl doesn't give such a opportunity.
On 31/07/2014 16:41, Roman Gareev wrote:
Tobias, could you please advise me how is it better to determine a
depth for loop (it is necessary for loop_is_parallel_p)? In
graphite-clast-to-gimple.c. it is done by using the number of
dimensions of a domain, which is attached to clast_for. As far as I
Hi.
I've had no luck building GCC on a Sparc-based Solaris machine here
since early March - right around the time some LTO related patches
landed. I've started trying again and the build fails when linking
libgcc_so at the end of stage1. Here's the end of the build log:
{ ... snip ... }
/bin/bas
Hi!
I've noticed that gcc's libstdc++ has implementations of
the zeta function and the hurwitz-zeta functions.
Is there any work going on with them?
Would an implementation of hurwitz_zeta in terms of the Polylogarithm be
helpful?
Thanks,
Florian.
Richard Biener writes:
> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni
> wrote:
>> Hi,
>>Sorry to ask a stupid question, but I am having issues writing patterns
>> involving casts. I am trying to write patterns from simplify_rotate.
>>
>> Could you show me how to write a patterns that
Snapshot gcc-4.8-20140731 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140731/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Jul 31, 2014 at 4:52 AM, NightStrike wrote:
>
> One thing you might want to consider is that with the typical X.Y.Z
> versioning of most GNU projects, changing X allows breaking
> compatibility in a significant way with previous versions. While Z
> fixes regressions and Y adds new feature
On Tue, Jul 29, 2014 at 10:27 AM, Markus Trippelsdorf
wrote:
> On 2014.07.29 at 19:14 +0200, Richard Biener wrote:
>> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou
>> wrote:
>> >> I think that if anybody has strong objections, now is the time to
>> >make
>> >> them. Otherwise I think we shoul
On Tue, Jul 29, 2014 at 9:45 AM, Eric Botcazou wrote:
>> I think that if anybody has strong objections, now is the time to make
>> them. Otherwise I think we should go with this plan.
>
> IMHO the cure is worse than the disease.
What do you propose that we do?
>> Given that there is no clear r
On 07/31/2014 07:03 PM, Ian Lance Taylor wrote:
On Thu, Jul 31, 2014 at 4:52 AM, NightStrike wrote:
One thing you might want to consider is that with the typical X.Y.Z
versioning of most GNU projects, changing X allows breaking
compatibility in a significant way with previous versions. While Z
On Thu, Jul 31, 2014 at 4:22 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 07/31/2014 07:03 PM, Ian Lance Taylor wrote:
>>
>> I believe the GCC project has become too large to be able to usefully
>> speak about breaking compatibility with previous versions. There are
>> too many different
On 07/31/2014 01:03 PM, Florian Goth wrote:
Hi!
I've noticed that gcc's libstdc++ has implementations of
the zeta function and the hurwitz-zeta functions.
Is there any work going on with them?
Would an implementation of hurwitz_zeta in terms of the Polylogarithm be
helpful?
Thanks,
Florian.
20 matches
Mail list logo
